SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Document Title

SOME/IP Service Discovery

Protocol Specification

Document Owner AUTOSAR

Document Responsibility AUTOSAR

Document Identification No 802

Document Status published

Part of AUTOSAR Standard Foundation

Part of Standard Release R22-11

Document Change History

Date Release Changed by

Description

2022-11-24 R22-11

AUTOSAR

Release

Management

• Contradicting requirements improved

• Editorial changes

2021-11-25 R21-11

AUTOSAR

Release

Management

• Removal of Explicit Initial Data

Control Flag and Initial Data

Requested Flag

• Introduced optional functionality to

subscribe to a multicast address

pre-defined by a ClientService

• Consideration of the connection

status of a security associations for

clients and servers was added

• Moved specification item from CP

SWS ServiceDiscovery to FO PRS

SOMEIPServiceDiscoveryProtocol

based on harmonization activities of

both documents

2020-11-30 R20-11

AUTOSAR

Release

Management

• Contradicting requirements improved

• Editorial changes

1 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

2019-11-28 R19-11

AUTOSAR

Release

Management

• Clarify:

– Startup Behavior (random

value)

– Service Versioning in VLAN

– Load Balancing option behavior

– Re-boot Detection

• Introduce retry max counter for

subscription of Eventgroup

• Contradicting requirements improved

• Editorial changes

• Changed Document Status from

Final to published

2019-03-29 1.5.1

AUTOSAR

Release

Management

• Editorial changes

2018-10-31 1.5.0

AUTOSAR

Release

Management

• Clarify load balancing option usage

• Contradicting requirements improved

• Redundant requirements removed

2018-03-29 1.4.0

AUTOSAR

Release

Management

• No content changes

2017-12-08 1.3.0

AUTOSAR

Release

Management

• minor changes

2017-10-27 1.2.0

AUTOSAR

Release

Management

• Editorial changes

2017-03-31 1.1.0

AUTOSAR

Release

Management

• Configuration Parameters SD_PORT

and SD_MULTICAST_IP are added

and defined

• Rules relating to Options are

reordered

2016-11-30 1.0.0

AUTOSAR

Release

Management

Initial Release

2 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Disclaimer

This work (specification and/or software implementation) and the material contained in

it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the

companies that have contributed to it shall not be liable for any use of the work.

The material contained in this work is protected by copyright and other types of intel-

lectual property rights. The commercial exploitation of the material contained in this

work requires a license to such intellectual property rights.

This work may be utilized or reproduced without any modification, in any form or by

any means, for informational purposes only. For any other purpose, no part of the work

may be utilized or reproduced, in any form or by any means, without permission in

writing from the publisher.

The work has been developed for automotive applications only. It has neither been

developed, nor tested for non-automotive applications.

The word AUTOSAR and the AUTOSAR logo are registered trademarks.

3 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Contents

1 Introduction and overview 6

1.1 Protocol purpose and objectives . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Applicability of the protocol . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 Constraints and assumptions . . . . . . . . . . . . . . . . . . 6

1.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1 Dependencies to other protocol layers . . . . . . . . . . . . . 7

2 Use Cases 8

3 Protocol Requirements 9

3.1 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Acronyms and Abbreviations 18

5 Protocol specification 20

5.1 SOME/IP Service Discovery (SOME/IP-SD) . . . . . . . . . . . . . . . 20

5.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1.1.1 Terms and Definitions . . . . . . . . . . . . . . . . . 20

5.1.2 SOME/IP-SD Message Format . . . . . . . . . . . . . . . . . 20

5.1.2.1 General Requirements . . . . . . . . . . . . . . . . . 20

5.1.2.2 SOME/IP-SD Header . . . . . . . . . . . . . . . . . . 23

5.1.2.3 Entry Format . . . . . . . . . . . . . . . . . . . . . . 26

5.1.2.4 Options Format . . . . . . . . . . . . . . . . . . . . . 29

5.1.2.5 Service Entries . . . . . . . . . . . . . . . . . . . . . 42

5.1.2.6 Endpoint Handling for Services and Events . . . . . 45

5.1.3 Service Discovery Messages . . . . . . . . . . . . . . . . . . 47

5.1.3.1 Eventgroup Entry . . . . . . . . . . . . . . . . . . . . 48

5.1.4 Service Discovery Communication Behavior . . . . . . . . . 52

5.1.4.1 Startup Behavior . . . . . . . . . . . . . . . . . . . . 52

5.1.4.2 Server Answer Behavior . . . . . . . . . . . . . . . . 55

5.1.4.3 Shutdown Behavior . . . . . . . . . . . . . . . . . . . 56

5.1.4.4 State Machines . . . . . . . . . . . . . . . . . . . . . 56

5.1.4.5 SOME/IP-SD Mechanisms and Errors . . . . . . . . 65

5.1.4.6 Error Handling . . . . . . . . . . . . . . . . . . . . . 67

5.1.5 Non-SOME/IP protocols with SOME/IP-SD . . . . . . . . . . 70

5.1.6 Publish/Subscribe with SOME/IP and SOME/IP-SD . . . . . 72

5.1.7 Reserved and special identifiers for SOME/IP and SOME/IP-

SD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6 Configuration Parameters 92

7 Protocol Usage 93

7.1 Mandatory Feature Set and Basic Behavior . . . . . . . . . . . . . . . 93

7.2 Migration and Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 96

7.2.1 Supporting multiple versions of the same service. . . . . . . 96

4 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

8 References 98

5 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

1 Introduction and overview

This protocol specification specifies the format, message sequences and semantics of

the Protocol SOME/IP Service Discovery (SOME/IP-SD).

The main tasks of the Service Discovery Protocol are communicating the availability of

functional entities called services in the in-vehicle communication as well as controlling

the send behavior of event messages. This allows sending only event messages to re-

ceivers requiring them (Publish/Subscribe). The solution described here is also known

as SOME/IP-SD (Scalable service-Oriented MiddlewarE over IP - Service Discovery).

1.1 Protocol purpose and objectives

SOME/IP-SD is used to

• Locate service instances.

• Detect if service instances are running.

• Implement the Publish/Subscribe handling.

1.2 Applicability of the protocol

SOME/IP SD can be used for service discovery in automotive vehicle networks.

1.2.1 Constraints and assumptions

The SOME/IP-SD has the following constraints:

• SOME/IP-SD supports only IP based communication.

• The network communication design has to consider the following limitations, if a

client service subscribes with an client service multicast endpoint announced via

a Multicast option:

– Communication which is based on a point to point connection may not be

working properly (e.g. End to end related communication, IPsec communi-

cation)

– Initial events have to be used carefully, because all client services sub-

scribed with the same multicast endpoint to the same server service, receive

the initial events every time a new client service is subscr ibed with the same

multicast endpoint to the same server service

6 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

1.3 Dependencies

1.3.1 Dependencies to other protocol layers

SOME/IP-SD depends on SOME/IP. SOME/IP itself supports both TCP and UDP

communications but SOME/IP SD is constraint to use SOME/IP only over UDP (See

[PRS_SOMEIPSD_00220]).

Figure 1.1: SOME/IP-SD Dependencies to other protocol layers

7 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

2 Use Cases

ID Name

Description

UC_001

Service

Offering

A Server is offering a service to the network without the

need to statically configure the server on client side

UC_002

Service

Subscription

A Client finds a desired service and subscribes to it

without knowing the Senders location

UC_003

Flexible com-

munication

paths

A developer wants to design his applications without

knowing who will receive the data or who is sending the

desired data. Service Discovery enables to establish

communication paths during integration time.

8 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

3 Protocol Requirements

3.1 Requirements Traceability

Feature Description Satisfied by

[RS_SOMEIPSD_00001] SOME/IP Service Discovery Protocol

shall be used on top of SOME/IP

Protocol

[PRS_SOMEIPSD_00151]

[PRS_SOMEIPSD_00152]

[PRS_SOMEIPSD_00153]

[PRS_SOMEIPSD_00154]

[PRS_SOMEIPSD_00156]

[PRS_SOMEIPSD_00157]

[PRS_SOMEIPSD_00158]

[PRS_SOMEIPSD_00159]

[PRS_SOMEIPSD_00160]

[PRS_SOMEIPSD_00161]

[PRS_SOMEIPSD_00162]

[PRS_SOMEIPSD_00163]

[PRS_SOMEIPSD_00164]

[PRS_SOMEIPSD_00250]

[PRS_SOMEIPSD_00251]

[PRS_SOMEIPSD_00252]

[PRS_SOMEIPSD_00600]

[RS_SOMEIPSD_00002] SOME/IP Service Discovery Protocol

shall support unicast messages

[PRS_SOMEIPSD_00256]

[PRS_SOMEIPSD_00259]

[PRS_SOMEIPSD_00540]

[PRS_SOMEIPSD_00601]

[PRS_SOMEIPSD_00602]

[PRS_SOMEIPSD_00631]

[PRS_SOMEIPSD_00702]

[RS_SOMEIPSD_00003] SOME/IP Service Discovery Protocol

shall support multicast messages

[PRS_SOMEIPSD_00238]

[PRS_SOMEIPSD_00239]

[PRS_SOMEIPSD_00256]

[PRS_SOMEIPSD_00323]

[PRS_SOMEIPSD_00324]

[PRS_SOMEIPSD_00325]

[PRS_SOMEIPSD_00326]

[PRS_SOMEIPSD_00331]

[PRS_SOMEIPSD_00332]

[PRS_SOMEIPSD_00333]

[PRS_SOMEIPSD_00545]

[PRS_SOMEIPSD_00601]

[PRS_SOMEIPSD_00603]

[PRS_SOMEIPSD_00631]

[PRS_SOMEIPSD_00847]

[PRS_SOMEIPSD_00848]

[PRS_SOMEIPSD_00849]

[PRS_SOMEIPSD_00850]

[RS_SOMEIPSD_00004] SOME/IP Service Discovery Protocol

shall support SOME/IP and non-SOME/

IP services

[PRS_SOMEIPSD_00437]

[PRS_SOMEIPSD_00438]

[PRS_SOMEIPSD_00439]

[PRS_SOMEIPSD_00440]

9 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIPSD_00005] SOME/IP Service Discovery Protocol

shall support different versions of the

same service

[PRS_SOMEIPSD_00512]

[PRS_SOMEIPSD_00806]

[RS_SOMEIPSD_00006] SOME/IP Service Discovery Protocol

shall define the format of the Service

Discovery message

[PRS_SOMEIPSD_00253]

[PRS_SOMEIPSD_00254]

[PRS_SOMEIPSD_00255]

[PRS_SOMEIPSD_00258]

[PRS_SOMEIPSD_00261]

[PRS_SOMEIPSD_00262]

[PRS_SOMEIPSD_00263]

[PRS_SOMEIPSD_00264]

[PRS_SOMEIPSD_00265]

[PRS_SOMEIPSD_00266]

[PRS_SOMEIPSD_00267]

[PRS_SOMEIPSD_00268]

[PRS_SOMEIPSD_00270]

[PRS_SOMEIPSD_00273]

[PRS_SOMEIPSD_00275]

[PRS_SOMEIPSD_00276]

[PRS_SOMEIPSD_00277]

[PRS_SOMEIPSD_00278]

[PRS_SOMEIPSD_00279]

[PRS_SOMEIPSD_00280]

[PRS_SOMEIPSD_00281]

[PRS_SOMEIPSD_00282]

[PRS_SOMEIPSD_00283]

[PRS_SOMEIPSD_00284]

[PRS_SOMEIPSD_00285]

[PRS_SOMEIPSD_00286]

[PRS_SOMEIPSD_00287]

[PRS_SOMEIPSD_00305]

[PRS_SOMEIPSD_00306]

[PRS_SOMEIPSD_00307]

[PRS_SOMEIPSD_00310]

[PRS_SOMEIPSD_00314]

[PRS_SOMEIPSD_00315]

[PRS_SOMEIPSD_00319]

[PRS_SOMEIPSD_00320]

[PRS_SOMEIPSD_00321]

[PRS_SOMEIPSD_00380]

[PRS_SOMEIPSD_00547]

[PRS_SOMEIPSD_00548]

[PRS_SOMEIPSD_00549]

[PRS_SOMEIPSD_00550]

[PRS_SOMEIPSD_00551]

[PRS_SOMEIPSD_00552]

[PRS_SOMEIPSD_00554]

[PRS_SOMEIPSD_00555]

[PRS_SOMEIPSD_00556]

[PRS_SOMEIPSD_00557]

[PRS_SOMEIPSD_00558]

10 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00559]

[PRS_SOMEIPSD_00650]

[PRS_SOMEIPSD_00651]

[PRS_SOMEIPSD_00654]

[PRS_SOMEIPSD_00807]

[PRS_SOMEIPSD_00835]

[PRS_SOMEIPSD_00836]

[PRS_SOMEIPSD_00837]

[PRS_SOMEIPSD_00838]

[PRS_SOMEIPSD_00845]

[RS_SOMEIPSD_00007] SOME/IP Service Discovery Protocol

shall define ordered feature sets for

compliance of implementations

[PRS_SOMEIPSD_00496]

[PRS_SOMEIPSD_00497]

[PRS_SOMEIPSD_00498]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00501]

[PRS_SOMEIPSD_00502]

[PRS_SOMEIPSD_00503]

[PRS_SOMEIPSD_00504]

[PRS_SOMEIPSD_00821]

[RS_SOMEIPSD_00008] SOME/IP Service Discovery Protocol

shall support to find the location of

service instances

[PRS_SOMEIPSD_00350]

[PRS_SOMEIPSD_00351]

[PRS_SOMEIPSD_00496]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00501]

[PRS_SOMEIPSD_00512]

[PRS_SOMEIPSD_00528]

[PRS_SOMEIPSD_00583]

[PRS_SOMEIPSD_00806]

[RS_SOMEIPSD_00009] SOME/IP Service Discovery Protocol

shall support to transport text-based

names of services

[PRS_SOMEIPSD_00277]

[RS_SOMEIPSD_00010] SOME/IP Service Discovery Protocol

shall provide support to transport

optional data

[PRS_SOMEIPSD_00220]

[PRS_SOMEIPSD_00305]

[PRS_SOMEIPSD_00306]

[PRS_SOMEIPSD_00307]

[PRS_SOMEIPSD_00310]

[PRS_SOMEIPSD_00314]

[PRS_SOMEIPSD_00315]

[PRS_SOMEIPSD_00319]

[PRS_SOMEIPSD_00320]

[PRS_SOMEIPSD_00321]

[PRS_SOMEIPSD_00380]

[PRS_SOMEIPSD_00547]

[PRS_SOMEIPSD_00548]

[PRS_SOMEIPSD_00549]

[PRS_SOMEIPSD_00550]

[PRS_SOMEIPSD_00551]

[PRS_SOMEIPSD_00552]

[PRS_SOMEIPSD_00554]

[PRS_SOMEIPSD_00555]

[PRS_SOMEIPSD_00556]

[PRS_SOMEIPSD_00557]

[PRS_SOMEIPSD_00558]

[PRS_SOMEIPSD_00559]

[PRS_SOMEIPSD_00650]

11 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00651]

[PRS_SOMEIPSD_00654]

[PRS_SOMEIPSD_00807]

[PRS_SOMEIPSD_00835]

[PRS_SOMEIPSD_00836]

[PRS_SOMEIPSD_00837]

[PRS_SOMEIPSD_00838]

[RS_SOMEIPSD_00011] SOME/IP Service Discovery Protocol

shall provide support for load balancing

[PRS_SOMEIPSD_00542]

[PRS_SOMEIPSD_00544]

[PRS_SOMEIPSD_00711]

[PRS_SOMEIPSD_00712]

[PRS_SOMEIPSD_00713]

[PRS_SOMEIPSD_00714]

[RS_SOMEIPSD_00012] SOME/IP Service Discovery Protocol

shall support to detect whether service

instances are active

[PRS_SOMEIPSD_00133]

[PRS_SOMEIPSD_00397]

[PRS_SOMEIPSD_00427]

[RS_SOMEIPSD_00013] SOME/IP Service Discovery Protocol

shall support to offer published services

[PRS_SOMEIPSD_00355]

[PRS_SOMEIPSD_00356]

[PRS_SOMEIPSD_00357]

[PRS_SOMEIPSD_00358]

[PRS_SOMEIPSD_00359]

[PRS_SOMEIPSD_00360]

[PRS_SOMEIPSD_00361]

[PRS_SOMEIPSD_00362]

[PRS_SOMEIPSD_00443]

[PRS_SOMEIPSD_00446]

[PRS_SOMEIPSD_00457]

[PRS_SOMEIPSD_00480]

[PRS_SOMEIPSD_00481]

[PRS_SOMEIPSD_00496]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00504]

[PRS_SOMEIPSD_00512]

[PRS_SOMEIPSD_00529]

[PRS_SOMEIPSD_00530]

[PRS_SOMEIPSD_00583]

[PRS_SOMEIPSD_00801]

[PRS_SOMEIPSD_00802]

[PRS_SOMEIPSD_00806]

[PRS_SOMEIPSD_00821]

[RS_SOMEIPSD_00014] SOME/IP Service Discovery Protocol

shall support to stop offering services

[PRS_SOMEIPSD_00363]

[PRS_SOMEIPSD_00364]

[PRS_SOMEIPSD_00443]

[PRS_SOMEIPSD_00446]

[PRS_SOMEIPSD_00496]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00583]

12 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIPSD_00015] SOME/IP Service Discovery Protocol

shall support to subscribe to events

[PRS_SOMEIPSD_00120]

[PRS_SOMEIPSD_00121]

[PRS_SOMEIPSD_00122]

[PRS_SOMEIPSD_00123]

[PRS_SOMEIPSD_00385]

[PRS_SOMEIPSD_00386]

[PRS_SOMEIPSD_00387]

[PRS_SOMEIPSD_00390]

[PRS_SOMEIPSD_00391]

[PRS_SOMEIPSD_00392]

[PRS_SOMEIPSD_00393]

[PRS_SOMEIPSD_00394]

[PRS_SOMEIPSD_00443]

[PRS_SOMEIPSD_00446]

[PRS_SOMEIPSD_00449]

[PRS_SOMEIPSD_00450]

[PRS_SOMEIPSD_00453]

[PRS_SOMEIPSD_00457]

[PRS_SOMEIPSD_00461]

[PRS_SOMEIPSD_00462]

[PRS_SOMEIPSD_00463]

[PRS_SOMEIPSD_00464]

[PRS_SOMEIPSD_00465]

[PRS_SOMEIPSD_00466]

[PRS_SOMEIPSD_00467]

[PRS_SOMEIPSD_00468]

[PRS_SOMEIPSD_00470]

[PRS_SOMEIPSD_00472]

[PRS_SOMEIPSD_00484]

[PRS_SOMEIPSD_00486]

[PRS_SOMEIPSD_00487]

[PRS_SOMEIPSD_00488]

[PRS_SOMEIPSD_00489]

[PRS_SOMEIPSD_00490]

[PRS_SOMEIPSD_00496]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00501]

[PRS_SOMEIPSD_00504]

[PRS_SOMEIPSD_00512]

[PRS_SOMEIPSD_00527]

[PRS_SOMEIPSD_00566]

[PRS_SOMEIPSD_00570]

[PRS_SOMEIPSD_00571]

[PRS_SOMEIPSD_00572]

[PRS_SOMEIPSD_00577]

[PRS_SOMEIPSD_00583]

[PRS_SOMEIPSD_00703]

[PRS_SOMEIPSD_00704]

13 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00806]

[PRS_SOMEIPSD_00808]

[PRS_SOMEIPSD_00809]

[PRS_SOMEIPSD_00810]

[PRS_SOMEIPSD_00811]

[PRS_SOMEIPSD_00821]

[PRS_SOMEIPSD_00828]

[PRS_SOMEIPSD_00830]

[PRS_SOMEIPSD_00831]

[PRS_SOMEIPSD_00842]

[PRS_SOMEIPSD_00846]

[PRS_SOMEIPSD_00851]

[RS_SOMEIPSD_00016] SOME/IP Service Discovery Protocol

shall support to deny subscriptions

[PRS_SOMEIPSD_00134]

[PRS_SOMEIPSD_00443]

[PRS_SOMEIPSD_00446]

[PRS_SOMEIPSD_00466]

[PRS_SOMEIPSD_00467]

[PRS_SOMEIPSD_00468]

[PRS_SOMEIPSD_00583]

[RS_SOMEIPSD_00017] SOME/IP Service Discovery Protocol

shall support to stop subscriptions to

events

[PRS_SOMEIPSD_00388]

[PRS_SOMEIPSD_00389]

[PRS_SOMEIPSD_00427]

[PRS_SOMEIPSD_00428]

[PRS_SOMEIPSD_00429]

[PRS_SOMEIPSD_00430]

[PRS_SOMEIPSD_00431]

[PRS_SOMEIPSD_00432]

[PRS_SOMEIPSD_00452]

[PRS_SOMEIPSD_00453]

[PRS_SOMEIPSD_00454]

[PRS_SOMEIPSD_00496]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00574]

[PRS_SOMEIPSD_00751]

[PRS_SOMEIPSD_00752]

[RS_SOMEIPSD_00018] SOME/IP Service Discovery Protocol

shall support reboot detection of

service providers

[PRS_SOMEIPSD_00503]

14 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[RS_SOMEIPSD_00019] SOME/IP Service Discovery Protocol

shall standardize error handling

[PRS_SOMEIPSD_00125]

[PRS_SOMEIPSD_00126]

[PRS_SOMEIPSD_00127]

[PRS_SOMEIPSD_00128]

[PRS_SOMEIPSD_00129]

[PRS_SOMEIPSD_00130]

[PRS_SOMEIPSD_00131]

[PRS_SOMEIPSD_00132]

[PRS_SOMEIPSD_00231]

[PRS_SOMEIPSD_00232]

[PRS_SOMEIPSD_00233]

[PRS_SOMEIPSD_00234]

[PRS_SOMEIPSD_00235]

[PRS_SOMEIPSD_00454]

[PRS_SOMEIPSD_00803]

[PRS_SOMEIPSD_00832]

[PRS_SOMEIPSD_00844]

[PRS_SOMEIPSD_00852]

[RS_SOMEIPSD_00020] SOME/IP Service Discovery Protocol

shall support TTL

[PRS_SOMEIPSD_00452]

[PRS_SOMEIPSD_00502]

[PRS_SOMEIPSD_00704]

[RS_SOMEIPSD_00021] SOME/IP Service Discovery protocol

shall provide functionality to discover

services

[PRS_SOMEIPSD_00350]

[PRS_SOMEIPSD_00351]

[RS_SOMEIPSD_00022] SOME/IP Service Discovery shall

operate in a distributed manner

[PRS_SOMEIPSD_00603]

[RS_SOMEIPSD_00024] SOME/IP Service Discovery shall

support configurable timings

[PRS_SOMEIPSD_00502]

[RS_SOMEIPSD_00025] SOME/IP Service Discovery messages

shall contain information how to contact

the communication partner

[PRS_SOMEIPSD_00133]

[PRS_SOMEIPSD_00134]

[PRS_SOMEIPSD_00341]

[PRS_SOMEIPSD_00342]

[PRS_SOMEIPSD_00343]

[PRS_SOMEIPSD_00356]

[PRS_SOMEIPSD_00357]

[PRS_SOMEIPSD_00358]

[PRS_SOMEIPSD_00359]

[PRS_SOMEIPSD_00360]

[PRS_SOMEIPSD_00361]

[PRS_SOMEIPSD_00362]

[PRS_SOMEIPSD_00387]

[PRS_SOMEIPSD_00395]

[PRS_SOMEIPSD_00397]

[PRS_SOMEIPSD_00399]

[PRS_SOMEIPSD_00400]

[PRS_SOMEIPSD_00401]

[PRS_SOMEIPSD_00404]

[PRS_SOMEIPSD_00405]

[PRS_SOMEIPSD_00406]

[PRS_SOMEIPSD_00407]

[PRS_SOMEIPSD_00408]

[PRS_SOMEIPSD_00409]

15 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00410]

[PRS_SOMEIPSD_00411]

[PRS_SOMEIPSD_00412]

[PRS_SOMEIPSD_00413]

[PRS_SOMEIPSD_00415]

[PRS_SOMEIPSD_00416]

[PRS_SOMEIPSD_00417]

[PRS_SOMEIPSD_00419]

[PRS_SOMEIPSD_00420]

[PRS_SOMEIPSD_00421]

[PRS_SOMEIPSD_00422]

[PRS_SOMEIPSD_00423]

[PRS_SOMEIPSD_00433]

[PRS_SOMEIPSD_00434]

[PRS_SOMEIPSD_00435]

[PRS_SOMEIPSD_00470]

[PRS_SOMEIPSD_00476]

[PRS_SOMEIPSD_00480]

[PRS_SOMEIPSD_00481]

[PRS_SOMEIPSD_00484]

[PRS_SOMEIPSD_00486]

[PRS_SOMEIPSD_00487]

[PRS_SOMEIPSD_00488]

[PRS_SOMEIPSD_00489]

[PRS_SOMEIPSD_00490]

[PRS_SOMEIPSD_00497]

[PRS_SOMEIPSD_00498]

[PRS_SOMEIPSD_00500]

[PRS_SOMEIPSD_00501]

[PRS_SOMEIPSD_00502]

[PRS_SOMEIPSD_00504]

[PRS_SOMEIPSD_00512]

[PRS_SOMEIPSD_00515]

[PRS_SOMEIPSD_00516]

[PRS_SOMEIPSD_00517]

[PRS_SOMEIPSD_00519]

[PRS_SOMEIPSD_00520]

[PRS_SOMEIPSD_00528]

[PRS_SOMEIPSD_00529]

[PRS_SOMEIPSD_00530]

[PRS_SOMEIPSD_00531]

[PRS_SOMEIPSD_00582]

[PRS_SOMEIPSD_00583]

[PRS_SOMEIPSD_00800]

[PRS_SOMEIPSD_00801]

[PRS_SOMEIPSD_00802]

[PRS_SOMEIPSD_00804]

[PRS_SOMEIPSD_00805]

16 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00806]

[PRS_SOMEIPSD_00810]

[PRS_SOMEIPSD_00821]

[PRS_SOMEIPSD_00828]

[PRS_SOMEIPSD_00833]

[PRS_SOMEIPSD_00834]

[PRS_SOMEIPSD_00843]

[PRS_SOMEIPSD_00846]

17 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

4 Acronyms and Abbreviations

The glossary below includes acronyms and abbreviations relevant to the SOME/IP

specification that are not included in the [1, AUTOSAR glossary].

Abbreviation / Acronym: Description:

Method

a method, procedure, function, or subroutine that is called/in-

voked.

Parameters input, output, or input/output arguments of a method or an event

Remote Procedure Call (RPC)

a method call from one ECU to another that is transmitted using

messages

Request a message of the client to the server invoking a method

Response

a message of the server to the client transporting results of a

method invocation

Request/Response communica-

tion

a RPC that consists of request and response

Fire&Forget communication a RPC call that consists only of a request message

Event

A uni-directional data transmission that is only invoked on

changes or cyclically and is sent from the producer of data to

the consumers. One event could even be both sent cyclically and

spontaneously on change. This is completely in the responsibility

of the sending application because the receiver has no means at

all to distinguish between those two.

Field

a field does represent a status and thus has a valid value at all

times on which getter, setter and notfier act upon.

Notification Event

an event message the notifier of a field sends. The message of

such a notifier cannot be distinguished from the event message;

therefore, when referring to the message of an event, this shall

also be true for the messages of notifiers of fields.

Getter a Request/Response call that allows read access to a field.

Setter a Request/Response call that allows write access to a field.

Notifier

sends out event message with a new value on change of the

value of the field.

Service

a logical combination of zero or more methods, zero or more

events, and zero or more fields (empty service is allowed, e.g.

for announcing non-SOME/IP services in SOME/IP-SD)

Eventgroup

a logical grouping of events and notification events of fields inside

a service in order to allow subscription

Service Interface

the formal specification of the service including its methods,

events, and fields

Service Instance

software implementation of the service interface, which can exist

more than once in the vehicle and more than once on an ECU

Server

The ECU offering a service instance shall be called server in the

context of this service instance.

Client

The ECU using the service instance of a server shall be called

client in the context of this service instance.

Union or Variant a data structure that dynamically assumes different data types.

Offering a service instance

that one ECU implements an instance of a service and tells other

ECUs using SOME/IP-SD that they may use it.

Finding a service instance

to send a SOME/IP-SD message in order to find a needed ser-

vice instance.

18 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Abbreviation / Acronym: Description:

Requiring a service instance

to send a SOME/IP-SD message to the ECU implementing the

required service instance with the meaning that this service in-

stance is needed by the other ECU. This may be also sent if the

service instance is not running; thus, was not offered yet.

Releasing a service instance

to sent a SOME/IP-SD message to the ECU hosting this service

instances with the meaning that the service instance is no longer

needed.

Server-Service-Instance-Entry

The configuration and required data of a service instance the

local ECU offers, is called Server-Service-Instance-Entry at the

ECU offering this service (Server).

Client-Service-Instance-Entry

The configuration and required data of a service instance another

ECU offers, is called Client-Service-Instance-Entry at the ECU

using this service (Client)

Publishing an eventgroup

to offer an eventgroup of a service instance to other ECUs using

a SOME/IP-SD message

Subscribing an eventgroup

to require an eventgroup of a service instance using a SOME/IP-

SD message.

unicast event

Events which are transmitted to a unicast endpoint by the ECU

which hosts a server service. The unicast endpoint is provided by

a particular client service which has subscribed to this server ser-

vice within the Endpoint Option referenced by a SubscribeEvent-

group entry (see client service unicast endpoint).

multicast event

Events which are transmitted to a multicast endpoint by the ECU

which hosts a server service. A multicast endpoint could be pro-

vided by the server service (see server service multicast end-

point) and client service (see client service multicast endpoint).

server service multicast end-

point

Multicast endpoint (including IP multicast address, port, and pro-

tocol) provided by the server service to announce where the

server service transmits multicast-events to with respect to the

configured MULTICAST_THRESHOLD.

client service unicast endpoint

Unicast endpoint (including IP multicast address, port, and pro-

tocol) provided by the client service to announce where the client

service expects to receive events from the corresponding server

service. Please note, if the MULTICAST_THRESHOLD has been

exceeded on server service side, then the server ser vice auto-

matically switches from the client service unicast endpoint to the

server service multicast endpoint to provide events.

client service multicast endpoint

Multicast endpoint (including IP multicast address, port, and pro-

tocol) provided by the client service to announce where the client

service expects to receive events from the corresponding server

service. This could be used alternatively to a client unicast end-

point. Please note, if the MULTICAST_THRESHOLD has been

exceeded on server service side, then the server ser vice auto-

matically switches from the client service multicast endpoint to

the server service multicast endpoint.

Security Association

Mechanism to provide secure encr ypted communication between

communication partners. This for example applies to IPSec,

MACsec, (d)TLS and possible other security protocols.

Secured Port

Network Port, on which a Security association is applied to be

secured from unauthorized communication.

Table 4.1: Acronyms and Abbreviations

19 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

5 Protocol specification

5.1 SOME/IP Service Discovery (SOME/IP-SD)

5.1.1 General

SOME/IP-SD is used to

• Locate service instances.

• Detect if service instances are running.

• Implement the Publish/Subscribe handling.

Inside the vehicular network service instance locations are commonly known; there-

fore, the state of the service instance is of primary concern. The location of the service

(i.e. IP-Address, transport protocol, and port number) are of secondary concern.

5.1.1.1 Terms and Definitions

[PRS_SOMEIPSD_00238] dA separate server service instance shall be used per net-

work interface if a service needs to be offered on multiple network interfaces.c(RS_-

SOMEIPSD_00003)

[PRS_SOMEIPSD_00239] dA separate client service instance shall be used per net-

work interface if a service needs to be configured to be accessed using multiple differ-

ent network interfaces.c(RS_SOMEIPSD_00003)

5.1.2 SOME/IP-SD Message Format

5.1.2.1 General Requirements

[PRS_SOMEIPSD_00220] dSOME/IP-SD messages shall be sent over UDP.c(RS_-

SOMEIPSD_00010)

[PRS_SOMEIPSD_00251] dThe SOME/IP-SD Header Format shall follow:

• Message ID (Service ID/Method ID) [32 bit]: 0xFFFF 8100

• Length [32 bit]

• Request ID (Client ID/Session ID) [32 bit]

• Protocol Version [8 bit]: 0x01

• Interface Version [8 bit]: 0x01

• Message Type [8 bit]: 0x02

20 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Return Code [8 bit]: 0x00

• Flags [8 bit]

• Reserved [24 bit]

• Length of Entries Array [32 bit]

• Entries Array [variable size]

• Length of Options Array [32 bit]

• Options Array [variable size]

c(RS_SOMEIPSD_00001)

The SOME/IP-SD Header Format is shown in Figure 5.1.

Protocol Version [8 bit]

=0x01

Interface Version [8 bit]

=0x01

Message Type [8 bit]

=0x02

Return Code [8 bit]

=0x00

Request ID (Client ID / Session ID) [32 bit]

Length [32 bit]

Message ID (Service ID / Method ID) [32 bit]

(= 0xFFFF 8100 )

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 bit offset

Covered by Length

Flags [8 bit] Reserved [24 bit]

Length of Entries Array [32 bit]

Entries Array

Length of Options Array [32 bit]

Options Array

Covered by LengthCovered by Length

SOME/IPSOME/IP SD

Figure 5.1: SOME/IP-SD Header Format

[PRS_SOMEIPSD_00250] dService Discovery Messages shall start with a SOME/IP

header.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00250] can be seen in Figure 5.1.

[PRS_SOMEIPSD_00151] dService Discovery messages shall use the Service-ID (16

Bits) of 0xFFFF.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00152] dService Discovery messages shall use the Method-ID (16

Bits) of 0x8100.c(RS_SOMEIPSD_00001)

21 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00153] dService Discovery messages shall use a uint32 length

field as specified by SOME/IP. That means that the length is measured in bytes and

starts with the first byte after the length field and ends with the last byte of the SOME/IP-

SD message.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00154] dService Discovery messages shall have a Client-ID (16

Bits) set to 0x0000, since there exists only a single SOME/IP-SD instance.c(RS_-

SOMEIPSD_00001)

[PRS_SOMEIPSD_00156] dService Discovery messages shall have a Session-ID (16

Bits) and handle it based on SOME/IP requirements.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00157] dThe Session-ID (SOME/IP header) shall be incremented

for every SOME/IP-SD message sent.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00158] dThe Session-ID (SOME/IP header) shall start with 1 and

be 1 even after wrapping.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00159] dThe Session-ID (SOME/IP header) shall not be set to 0.c

(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00160] dSOME/IP-SD Session ID handling is done per "com-

munication relation", i.e. multicast as well as unicast per peer (see

[PRS_SOMEIPSD_00255]).c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00161] dService Discovery messages shall have a Protocol-

Version (8 Bits) of 0x01.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00162] dService Discovery messages shall have a Interface-

Version (8 Bits) of 0x01.c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00163] dService Discovery messages shall have a Message Type

(8 bits) of 0x02 (Notification).c(RS_SOMEIPSD_00001)

[PRS_SOMEIPSD_00164] dService Discovery messages shall have a Return Code (8

bits) of 0x00 (E_OK).c(RS_SOMEIPSD_00001)

22 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

An example of SOME/IP-SD is as shown below

Figure 5.2: SOME/IP-SD Example PDU

5.1.2.2 SOME/IP-SD Header

[PRS_SOMEIPSD_00252] dSOME/IP-SD shall be transported using SOME/IP.c(RS_-

SOMEIPSD_00001)

[PRS_SOMEIPSD_00252] can be seen in Figure 5.2.

23 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00253] dThe SOME/IP-SD Header shall start with an 8 Bit field

called flags.c(RS_SOMEIPSD_00006)

See a representation of Flags in Figure 5.3.

Figure 5.3: Flags in SOME/IP-SD

[PRS_SOMEIPSD_00254] dThe first flag of the SOME/IP-SD Flags field (highest order

bit) shall be called Reboot Flag.c(RS_SOMEIPSD_00006)

For flags see Figure 5.3.

[PRS_SOMEIPSD_00255] dThe Reboot Flag of the SOME/IP-SD Header shall be set

to one for all messages after reboot until the Session-ID in the SOME/IP-Header wraps

around and thus starts with 1 again. After this wrap around the Reboot Flag is set to

0.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00256] dThe information for the reboot flag and the Session ID

shall be kept for multicast and unicast separately.c(RS_SOMEIPSD_00002, RS_-

SOMEIPSD_00003)

[PRS_SOMEIPSD_00631] dThe information for the reboot flag and the Session ID

shall be kept for every sender-receiver relation (i.e. source address and destination

address) separately.c(RS_SOMEIPSD_00002, RS_SOMEIPSD_00003)

Note:

This means there shall be separate counters for sending and receiving.

Sending

• There shall be a counter for multicast.

• There shall be a separate counter for each peer for unicast.

Receiving

24 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• There shall be a counter for each peer for multicast.

• There shall be a counter for each peer for unicast.

[PRS_SOMEIPSD_00258] dThe detection of a reboot shall be done as follows (with

the new values of the current packet from the communication partner and old the last

value received before):

if old.reboot==0 and new.reboot==1 then Reboot detected

if old.reboot==1 and new.reboot==1 and old.session_id>=new.session_id then Reboot

detected

c(RS_SOMEIPSD_00006)

Note:

The following is not enough since we do not have reliable communication:

if new.reboot==1 and old.session_id>=new.session_id then Reboot detected

[PRS_SOMEIPSD_00259] dThe second flag of the SOME/IP-SD Flags (second high-

est order bit) shall be called Unicast Flag.c(RS_SOMEIPSD_00002)

For flags see Figure 5.3.

[PRS_SOMEIPSD_00540] dThe Unicast Flag of the SOME/IP-SD Header shall be set

to Unicast (that means 1) for all SD Messages since this means that receiving using

unicast is supported.c(RS_SOMEIPSD_00002)

Note:

The Unicast Flag is left over from historical SOME/IP versions and is only kept for

compatibility reasons. Its use besides this is very limited.

For flags see Figure 5.3.

[PRS_SOMEIPSD_00702] dUndefined bits within the Flag field shall be set to ’0’ when

sending and ignored on receiving.c(RS_SOMEIPSD_00002)

[PRS_SOMEIPSD_00261] dAfter the Flags the SOME/IP-SD Header shall have a field

of 24 bits called Reserved.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00262] dAfter the SOME/IP-SD Header the Entries Array shall fol-

low.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00263] dThe entries shall be processed exactly in the order they

arrive.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00264] dAfter the Entries Array in the SOME/IP-SD Header an Op-

tion Array shall follow.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00265] dThe Entries Array and the Options Array of the SOME/IP-

SD message shall start with a length field as uint32 that counts the number of bytes

of the following data; i.e. the entries or the options.c(RS_SOMEIPSD_00006)

25 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

5.1.2.3 Entry Format

[PRS_SOMEIPSD_00266] dThe service discovery shall support multiple entries that

are combined in one service discovery message.c(RS_SOMEIPSD_00006)

Note:

The entries are used to synchronize the state of services instances and the Publish/-

Subscribe handling.

[PRS_SOMEIPSD_00267] dTwo types of entries exist: A Service Entry Type for Ser-

vices and an Eventgroup Entry Type for Eventgroups.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00268] dA Service Entry Type shall be 16 Bytes of size and include

the following fields in this order:

• Type Field [uint8]: encodes FindService (0x00), OfferService (0x01) and StopOf-

ferService (0x01)

• Index First Option Run [uint8]: Index of this runs first option in the option array.

• Index Second Option Run [uint8]: Index of this runs second option in the option

array.

• Number of Options 1 [uint4]: Describes the number of options the first option run

uses.

• Number of Options 2 [uint4]: Describes the number of options the second option

run uses.

• Service-ID [uint16]: Describes the Service ID of the Service or Service-Instance

this entry is concerned with.

• Instance ID [uint16]: Describes the Service Instance ID of the Service Instance

this entry is concerned with or is set to 0xFFFF if all service instances of a service

are meant.

• Major Version [uint8]: Encodes the major version of the service (instance).

• TTL [uint24]: Describes the lifetime of the entry in seconds.

• Minor Version [uint32]: Encodes the minor version of the service.

c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00268] is shown in Figure 5.4.

26 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Type

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 bit offset

Index 1st options Index 2nd options # of opt 1 # of opt 2

Service ID Instance ID

Major Version TTL

Minor Version

Figure 5.4: SOME/IP-SD Service Entr y Type

[PRS_SOMEIPSD_00270] dAn Eventgroup Entry (Type 2) shall be 16 Bytes of size

and include the following fields in this order:

• Type Field [uint8]: encodes Subscribe (0x06), StopSubscribeEventgroup (0x06),

SubscribeAck (0x07) and SubscribeEventgroupNack (0x07).

• Index of first option run [uint8]: Index of this runs first option in the option array.

• Index of second option run [uint8]: Index of this runs second option in the option

array.

• Number of Options 1 [uint4]: Describes the number of options the first option run

uses.

• Number of Options 2 [uint4]: Describes the number of options the second option

run uses.

• Service-ID [uint16]: Describes the Service ID of the Service or Service Instance

this entry is concerned with.

• Instance ID [uint16]: Describes the Service Instance ID of the Service Instance

this entry is concerned with. The Service Instance ID shall not be set to 0xFFFF

for any Instance.

• Major Version [uint8]: Encodes the major version of the service instance this

eventgroup is part of.

• TTL [uint24]: Descibes the lifetime of the entry in seconds.

• Reserved [uint12]: Shall be set to 0x000.

• Counter [uint4]: Is used to differentiate identical Subscribe Eventgroups of the

same subscriber. Set to 0x0 if not used.

• Eventgroup ID [uint16]: Transpor ts the ID of an Eventgroup.

c(RS_SOMEIPSD_00006)

SOME/IP-SD Eventgroup Entry Type is shown in Figure 5.5.

27 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Figure 5.5: SOME/IP-SD Eventgroup Entry Type

[PRS_SOMEIPSD_00845] dThe Major Version of an entry (according to

[PRS_SOMEIPSD_00268] and [PRS_SOMEIPSD_00270]) shall match the ver-

sion of the corresponding Service Interfacec(RS_SOMEIPSD_00006)

Note: For Service Discovery on Classic Platform the Major version of SdServerSer-

vice and SdClientService, respectively, has to match the Interface Version of the cor-

responding Service Interface

Referencing Options from Entries

[PRS_SOMEIPSD_00833] dUsing the following fields of the entries, options are refer-

enced by the entries:

• Index First Option Run: Index into array of options for first option run. Index 0

means first of SOME/IP-SD packet.

• Index Second Option Run: Index into array of options for second option run. Index

0 means first of SOME/IP-SD packet.

• Number of Options 1: Length of first option run. Length 0 means no option in

option run.

• Number of Options 2: Length of second option run. Length 0 means no option in

option run.

c(RS_SOMEIPSD_00025)

Two different option runs exist: First Option Run and Second Option Run.

Rationale for the support of two option runs: Two different types of options are ex-

pected: options common between multiple SOME/IP-SD entries and options different

for each SOME/IP-SD entry. Supporting two different options runs is the most efficient

way to support these two types of options, while keeping the wire format highly efficient.

[PRS_SOMEIPSD_00341] dEach option run shall reference the first option and the

number of options for this run.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00342] dIf the number of options is set to zero, the option run is

considered empty.c(RS_SOMEIPSD_00025)

28 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00343] dFor empty runs the Index (i.e. Index First Option Run

and/or Index Second Option Run) shall be set to zero.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00834] dImplementations shall accept and process incoming SD

messages with option run length set to zero and option index not set to zero.c(RS_-

SOMEIPSD_00025)

5.1.2.4 Options Format

Options are used to transport additional information to the entries. This includes for

instance the information how a service instance is reachable (IP-Address, Transport

Protocol, Port Number).

[PRS_SOMEIPSD_00273] dIn order to identify the option type every option shall start

with:

• Length [uint16]: Specifies the length of the option in Bytes.

• Type [uint8]: Specifying the type of the option.

• Discardable Flag [1 bit]: Specifies if the option can be discarded.

• Bit 1 to bit 7 are reserved and shall be 0.

c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00275] dThe discardable flag shall be set to 1 if the option can be

discarded by a receiving ECU that does not support this option.c(RS_SOMEIPSD_-

00006)

Configuration Option

The configuration option is used to transport arbitrary configuration strings. This allows

to encode additional information like the name of a service or its configuration.

[PRS_SOMEIPSD_00276] dThe format of the Configuration Option shall be as follows:

• Length [uint16]: Shall be set to the total number of bytes occupied by the config-

uration option, excluding the 16 bit length field and the 8 bit type flag.

• Type [uint8]: Shall be set to 0x01.

• Discardable Flag [1 bit]: Shall be set to 1 if the Option can be discarded by the

receiver.

• Bit 1 to bit 7 are reserved and shall be 0.

• ConfigurationString [dyn length]: Shall carry the configuration string.

c(RS_SOMEIPSD_00006)

29 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00277] dThe Configuration Option shall specify a set of name-

value-pairs based on the DNS TXT and DNS-SD format.c(RS_SOMEIPSD_00006,

RS_SOMEIPSD_00009)

[PRS_SOMEIPSD_00278] dThe format of the configuration string shall start with a

single byte length field that describes the number of bytes following this length field.

After the length field a character sequence with the specified length shall follow.c(RS_-

SOMEIPSD_00006)

[PRS_SOMEIPSD_00279] dAfter each character sequence another length field and a

following character sequence are expected until a length field shall be set to 0x00.c

(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00280] dAfter a length field is set to 0x00 no characters shall fol-

low.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00281] dA character sequence shall encode a key and optionally a

value.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00282] dThe character sequences shall contain an equal character

("=", 0x3D) to divide key and value.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00283] dThe key shall not include an equal character and shall be

at least one non-whitespace character. The characters of "Key" shall be printable US-

ASCII values (0x20-0x7E), excluding ’=’ (0x3D).c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00284] dThe "=" shall not be the first character of the sequence.c

(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00285] dFor a character sequence without an ’=’ that key shall be

interpreted as present.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00286] dFor a character sequence ending on an ’=’ that key shall

be interpreted as present with empty value.c(RS_SOMEIPSD_00006)

[PRS_SOMEIPSD_00287] dMultiple entries with the same key in a single Configuration

Option shall be supported.c(RS_SOMEIPSD_00006)

The format of the Configuration Option is shown in Figure 5.6.

Figure 5.6: SOME/IP-SD Configuration Option

Example for SOME/IP-SD Configuration Option

30 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Figure 5.7: SOME/IP-SD Configuration Option Example

Load Balancing Option

The Load Balancing option is used to prioritize different instances of a service, so that

a client chooses the service instance based on these settings. This option will be

attached to Offer Service entries.

[PRS_SOMEIPSD_00542] dThe Load Balancing Option shall carry a Priority and

Weight like the DNS-SRV records, which shall be used for load balancing different

service instances.c(RS_SOMEIPSD_00011)

[PRS_SOMEIPSD_00711] dWhen looking for all service instances of a service (Ser-

vice Instance set to 0xFFFF), the client shall choose the service instance with highest

priority that also matches client specific criteria.c(RS_SOMEIPSD_00011)

Note: Client specific criteria may be applied by the client application when choosing

one of the offered service instances. They are not defined in this specification, and

could e.g. restrict the range of appropriate instance IDs.

[PRS_SOMEIPSD_00712] dWhen having more than one service instance with highest

priority (lowest value in Priority field) the service instance shall be chosen randomly

based on the weights of the service instances. The probability of choosing a service

instance shall be the weight of a service instance divided by the sum of the weights of

all considered service instances.c(RS_SOMEIPSD_00011)

[PRS_SOMEIPSD_00713] dIf an Offer Service entry references no Load Balancing

option and several service instances are offered, the client shall handle the service

instances without Load Balancing option as though they had the lowest priority.c(RS_-

SOMEIPSD_00011)

[PRS_SOMEIPSD_00714] dWhen looking for a specific service instances of a service

(Service Instance set to any value other than 0xFFFF), the evaluation of the Load

Balancing Option does not apply.c(RS_SOMEIPSD_00011)

[PRS_SOMEIPSD_00544] dThe Format of the Load Balancing Option shall be as fol-

lows:

• Length [uint16]: Shall be set to 0x0005.

31 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Type [uint8]: Shall be set to 0x02.

• Discardable Flag [1 bit]: Shall be set to 1 if the Option can be discarded by the

receiver.

• Bit 1 to bit 7 are reserved and shall be 0.

• Priority [uint16]: Carr ies the Priority of this instance. Lower value means higher

priority.

• Weight [uint16]: Carries the Weight of this instance. Large value means higher

probability to be chosen.

c(RS_SOMEIPSD_00011)

The format of the Load Balancing Option is shown in Figure 5.8.

Figure 5.8: SOME/IP-SD Load Balancing Option

IPv4 Endpoint Option

The IPv4 Endpoint Option is used by a SOME/IP-SD instance to signal the relevant

endpoint(s). Endpoints include the local IP address, the transport layer protocol (e.g.

UDP or TCP), and the port number of the sender. These ports are used for the events

and notification events as well.

[PRS_SOMEIPSD_00305] dThe IPv4 Endpoint Option shall use the Type 0x04.c(RS_-

SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00306] dThe IPv4 Endpoint Option shall specify the IPv4-Address,

the transport layer protocol (ISO/OSI layer 4) used, and its Port Number.c(RS_-

SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00307] dThe Format of the IPv4 Endpoint Option shall be as fol-

lows:

• Length [uint16]: Shall be set to 0x0009.

• Type [uint8]: Shall be set to 0x04.

• Discardable Flag [1 bit]: Shall be set to 0.

• Bit 1 to bit 7 are reserved and shall be 0.

• IPv4-Address [uint32]: Shall transport the unicast IP-Address as four Bytes.

32 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Reserved [uint8]: Shall be set to 0x00.

• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol

(ISO/OSI layer 4) based on the IANA/IETF types (0x06: TCP, 0x11: UDP).

• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the port of the

layer 4 protocol.

c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

SOME/IP-SD IPv4 Endpoint Option is shown in Figure 5.9.

Figure 5.9: SOME/IP-SD IPv4 Endpoint Option

[PRS_SOMEIPSD_00310] dThe server shall use the IPv4 Endpoint Option with Offer

Service entries to signal the endpoints it serves the service on. That is upto one UDP

endpoint and upto one TCP endpoint.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_-

00010)

[PRS_SOMEIPSD_00380] dThe endpoints the server referenced with an Offer Service

entry shall also be used as source of events. That is source IP address and source port

numbers for the transport protocols in the endpoint option.c(RS_SOMEIPSD_00006,

RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00807] dThe client shall use the IPv4 Endpoint Option with Sub-

scribe Eventgroup entries to signal the IP address and the UDP and/or TCP port

numbers, on which it is ready to receive the events.c(RS_SOMEIPSD_00006, RS_-

SOMEIPSD_00010)

Note: The client is ready to receive the events, if sockets are already opened, and

any security associations required by the network security protocols (IPsec, MACsec

or other security protocols) are already established and fully operational.

[PRS_SOMEIPSD_00835] dDifferent provided service instances of the same service

on the same ECU shall use different endpoints, so that they can be differentiated by

the endpoints. Different services may share the same endpoints.c(RS_SOMEIPSD_-

00006, RS_SOMEIPSD_00010)

IPv6 Endpoint Option

The IPv6 Endpoint Option is used by a SOME/IP-SD instance to signal the relevant

endpoint(s). Endpoints include the local IP address, the transport layer protocol (e.g.

33 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

UDP or TCP), and the port number of the sender. These ports are used for the events

and notification events as well.

[PRS_SOMEIPSD_00314] dThe IPv6 Endpoint Option shall use the Type 0x06.c(RS_-

SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00315] dThe Format of the IPv6 Endpoint Option shall be as fol-

lows:

• Length [uint16]: Shall be set to 0x0015.

• Type [uint8]: Shall be set to 0x06.

• Discardable Flag [1 bit]: Shall be set to 0.

• Bit 1 to bit 7 are reserved and shall be 0.

• IPv6-Address [uint128]: Shall transport the unicast IP-Address as 16 Bytes.

• Reserved [uint8]: Shall be set to 0x00.

• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol

(ISO/OSI layer 4) based on the IANA/IETF types (0x06: TCP, 0x11: UDP).

• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the transport

layer port(e.g. 30490).

c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

SOME/IP-SD IPv6 Endpoint Option shall be as shown in Figure 5.10

Figure 5.10: SOME/IP-SD IPv6 Endpoint Option

[PRS_SOMEIPSD_00319] dThe server shall use the IPv6 Endpoint Option with Of-

fer Service entries to signal the endpoints the services is available on. That is

upto one UDP endpoint and upto one TCP endpoint.c(RS_SOMEIPSD_00006, RS_-

SOMEIPSD_00010)

[PRS_SOMEIPSD_00320] dThe endpoints the server referenced with an Offer Service

entry shall also be used as source of events. That is source IP address and source port

numbers for the transport protocols in the endpoint option.c(RS_SOMEIPSD_00006,

RS_SOMEIPSD_00010)

34 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00321] dThe client shall use the IPv6 Endpoint Option with Sub-

scribe Eventgroup entries to signal the IP address and the UDP and/or TCP port

numbers, on which it is ready to receive the events.c(RS_SOMEIPSD_00006, RS_-

SOMEIPSD_00010)

Note:

• The client is ready to receive the events, if sockets are already opened, and any

security associations required by the network security protocols (IPsec, MACsec

or other security protocols) are already established and fully operational

• Security association status monitoring and its implications towards Service dis-

covery shall apply for all Service Instances using secured ports.

[PRS_SOMEIPSD_00836] dDifferent service instances of the same service on the

same ECU shall use different endpoints, so that they can be distinguished by the end-

points. Different services may share the same endpoints.c(RS_SOMEIPSD_00006,

RS_SOMEIPSD_00010)

IPv4 Multicast Option

The IPv4 Multicast Option is either transmitted by the server service (server service

multicast endpoint) or by the client service (client service multicast endpoint):

• If it is transmitted by the server service, then a server announces the IPv4 multi-

cast address, the transport layer protocol (ISO/OSI layer 4), and the port number,

to where the multicast-events and multicast-notification-events are transmitted to.

• If it is transmitted by the client service, then a client indicates the IPv4 multi-

cast address, the transport layer protocol (ISO/OSI layer 4), and the port num-

ber, where a client expects to receive multicast-events and multicast-notification-

events.

[PRS_SOMEIPSD_00323] d

IPv4 Multicast Options shall be referenced by SubscribeEventgroup or by StopSub-

scribeEventgroup or by SubscribeEventgroupAck entries:

• If it is referenced by a Subscr ibeEventgroup entry, it describes the client service

multicast endpoint (i.e. destination IP address and destination port), where the

multicast-events shall be received by the client.

• If it is referenced by a StopSubscribeEventgroup entry, it reflects the intent to

stop the subscription of a client which has subscribed before via a client service

multicast endpoint (i.e. destination IP address and destination port) to the given

event group.

• If it is referenced by a SubscribeEventgroupAck entry, it describes the server ser-

vice multicast endpoint (i.e. destination IP address and destination port), where

a server shall transmit the multicast-events to.

35 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

c(RS_SOMEIPSD_00003)

[PRS_SOMEIPSD_00324] dThe IPv4 Multicast Option shall use the Type 0x14.c(RS_-

SOMEIPSD_00003)

[PRS_SOMEIPSD_00325] dThe IPv4 Multicast Option shall specify the IPv4-Address,

the transport layer protocol (ISO/OSI layer 4) used, and its Port Number.c(RS_-

SOMEIPSD_00003)

[PRS_SOMEIPSD_00326] dThe Format of the IPv4 Endpoint Option shall be as fol-

lows:

• Length [uint16]: Shall be set to 0x0009.

• Type [uint8]: Shall be set to 0x14.

• Discardable Flag [1 bit]: Shall be set to 0.

• Bit 1 to bit 7 are reserved and shall be 0.

• IPv4-Address [uint32]: Shall transport the multicast IP-Address as four Bytes.

• Reserved [uint8]: Shall be set to 0x00.

• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol

(ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP).

• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the port of the

layer 4 protocol.

c(RS_SOMEIPSD_00003)

SOME/IP-SD IPv4 Multicast Option shall be as shown in Figure 5.11

Figure 5.11: SOME/IP-SD IPv4 Multicast Option

[PRS_SOMEIPSD_00847] d

The IPv4-Address field [32 bits] of the IPv4 Multicast Option shall be set according the

following rules:

• If a server service transmits a SubscribeEventgroupAck then the field shall be set

to the configured multicast IP address of the corresponding provided Eventgroup

(server service multicast endpoint).

• If a client service transmit a SubscribeEventgroup or StopSubscribeEventgroup,

then the field shall be set to the configured multicast IP address of the corre-

sponding consumed Eventgroup (client service multicast endpoint).

36 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

c(RS_SOMEIPSD_00003)

[PRS_SOMEIPSD_00848] d

The Port Number field [16 bits] of the IPv4 Multicast Option shall be set according the

following rules

• If a server service transmits a SubscribeEventgroupAck then the field shall be set

to the configured port of the corresponding provided Eventgroup (server service

multicast endpoint).

• If a client service transmits a SubscribeEventgroup or StopSubscribeEventgroup,

then the field shall be set to the configured port of the corresponding consumed

Eventgroup (client service multicast endpoint).

c(RS_SOMEIPSD_00003)

IPv6 Multicast Option

The IPv6 Multicast Option is either transmitted by the server service (server service

multicast endpoint) or by the client service (client service multicast endpoint):

• If it is transmitted by the server service, then a server announces the IPv6 multi-

cast address, the transport layer protocol (ISO/OSI layer 4), and the port number,

to where the multicast-events and multicast-notification-events are transmitted to.

• If it is transmitted by the client service, then a client indicates the IPv6 multi-

cast address, the transport layer protocol (ISO/OSI layer 4), and the port num-

ber, where a client expects to receive multicast-events and multicast-notification-

events.

[PRS_SOMEIPSD_00331] dThe IPv6 Multicast Option shall use the Type 0x16.c(RS_-

SOMEIPSD_00003)

[PRS_SOMEIPSD_00332] dThe IPv6 Multicast Option shall specify the IPv6-Address,

the transport layer protocol (ISO/OSI layer 4) used, and its Port Number.c(RS_-

SOMEIPSD_00003)

[PRS_SOMEIPSD_00333] dThe Format of the IPv6 Multicast Option shall be as fol-

lows:

• Length [uint16]: Shall be set to 0x0015.

• Type [uint8]: Shall be set to 0x16.

• Discardable Flag [1 bit]: Shall be set to 0.

• Bit 1 to bit 7 are reserved and shall be 0.

• IPv6-Address [uint128]: Shall transport the multicast IP-Address as 16 Bytes.

• Reserved [uint8]: Shall be set to 0x00.

37 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol

(ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP).

• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the port of the

layer 4 protocol.

c(RS_SOMEIPSD_00003)

SOME/IP-SD IPv6 Multicast Option shall be as shown in Figure 5.12.

Figure 5.12: SOME/IP-SD IPv6 Multicast Option

[PRS_SOMEIPSD_00849] dThe IPv6-Address field [128 bits] of the IPv6 Multicast op-

tion shall be set according the following rules:

• If a server service transmits a SubscribeEventgroupAck then the field shall be set

to the configured multicast IP address of the corresponding provided Eventgroup

(server service multicast endpoint).

• If a client service transmits a SubscribeEventgroup or StopSubscribeEventgroup,

then the field shall be set to the configured IP multicast address of the corre-

sponding consumed Eventgroup (client service multicast endpoint).

c(RS_SOMEIPSD_00003)

[PRS_SOMEIPSD_00850] dThe Port Number field [16 bits] of the IPv6 Multicast Op-

tion shall be set according the following rules:

• If a server service transmits a SubscribeEventgroupAck then the field shall be set

to the configured port of the corresponding provided Eventgroup (server service

multicast endpoint).

• If a client service transmits a SubscribeEventGroup or StopSubscribeEvent-

Group, then the field shall be set to the configured port of the corresponding

consumed Eventgroup (client service multicast endpoint).

c(RS_SOMEIPSD_00003)

[PRS_SOMEIPSD_00545] dIPv6 Multicast Options shall be referenced by Sub-

scribeEventgroup or by StopSubscribeEventgroup or by SubscribeEventgroupAck en-

tries:

38 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• If it is referenced by a Subscr ibeEventgroup entry, it describes the client service

multicast endpoint (i.e. destination IP address and destination port), where the

multicast-events shall be received by the client.

• If it is referenced by a StopSubscribeEventgroup entry, it reflects the intent to

stop the subscription of a client which has subscribed before via a client service

multicast multicast endpoint (i.e. destination IP address and destination port) to

the given event group.

• If it is referenced by a SubscribeEventgroupAck entry, it describes the server ser-

vice multicast endpoint (i.e. destination IP address and destination port), where

a server shall transmit the multicast-events to.

c(RS_SOMEIPSD_00003)

IPv4 SD Endpoint Option

The IPv4 SD Endpoint Option is used to transport the endpoint (i.e. IP-Address and

Port) of the senders SD implementation. This is used to identify the SOME/IP-SD

Instance even in cases in which the IP-Address and/or Port Number cannot be used.

Note:

This is used to identify the SOME/IP-SD Instance even in cases in which the IP-

Address and/or Port Number cannot be used. A use case would be a proxy service

discovery on one ECU which handles the multicast traffic for another ECU.

SOME/IP-SD IPv4 SD Endpoint Option is shown in Figure 5.13

Figure 5.13: SOME/IP-SD IPv4 SD Endpoint Option

[PRS_SOMEIPSD_00547] dThe IPv4 SD Endpoint Option shall be included in any SD

message up to 1 time.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00650] dThe IPv4 SD Endpoint Option shall only be included if

the SOME/IP-SD message is transported over IPv4.c(RS_SOMEIPSD_00006, RS_-

SOMEIPSD_00010)

[PRS_SOMEIPSD_00651] dThe IPv4 SD Endpoint Option shall be the first option in

the options array, if existing.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00548] dThe IPv4 SD Endpoint Option shall not be referenced by

any SD Entry.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00549] dIf the IPv4 SD Endpoint Option is included in the SD mes-

sage, the receiving SD Service Instance shall use the content of this option instead of

39 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

the Source IP Address and Source Port.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_-

00010)

Note:

This is important for answering the received SD message (e.g. Offer after Find or

Subscribe after Offer or Subscribe Ack after Subscribe) as well as the reboot detection

(channel based on SD Endpoint Option and not out addresses).

[PRS_SOMEIPSD_00550] dThe IPv4 SD Endpoint Option shall use the Type 0x24.c

(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00551] dThe IPv4 SD Endpoint Option shall specify the IPv4-

Address, the transport layer protocol (ISO/OSI layer 4) and Port Number of the sender

used for Service Discovery.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00552] dThe Format of the IPv4 SD Endpoint Option shall be as

follows:

• Length [uint16]: Shall be set to 0x0009.

• Type [uint8]: Shall be set to 0x24.

• Discardable Flag [1 bit]: Shall be set to 0.

• Bit 1 to bit 7 are reserved and shall be 0.

• IPv4-Address [uint32]: Shall transport the unicast IP-Address of SOME/IP-SD as

four Bytes.

• Reserved [uint8]: Shall be set to 0x00.

• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol

of SOME/IP-SD (currently: 0x11 UDP).

• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the transport

layer port of SOME/IP-SD (currently: 30490).

c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

IPv6 SD Endpoint Option

The Ipv6 SD Endpoint Option is used to transport the endpoint (i.e. IP-Address and

Port) of the senders SD implementation. This is used to identify the SOME/IP-SD

Instance even in cases in which the IP-Address and/or Port Number cannot be used.

SOME/IP-SD IPv6 SD Endpoint Option is shown in Figure 5.14

Note:

A use case would be a proxy service discovery on one ECU which handles the multi-

cast traffic for another ECU.

40 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Figure 5.14: SOME/IP-SD IPv6 SD Endpoint Option

[PRS_SOMEIPSD_00554] dThe IPv6 SD Endpoint Option may be included in any SD

message up to 1 time.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00654] dThe IPv6 SD Endpoint Option shall be the first option in

the options array, if existing.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00555] dThe IPv6 SD Endpoint Option shall not be referenced by

any SD Entry.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00556] dIf the IPv6 SD Endpoint Option is included in the SD mes-

sage, the receiving SD Service Instance shall use the content of this option instead

of the Source IP Address and Source Port for answering this SD messages.c(RS_-

SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00557] dThe IPv6 SD Endpoint Option shall use the Type 0x26.c

(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00558] dThe IPv6 SD Endpoint Option shall specify the IPv6-

Address, the transport layer protocol (ISO/OSI layer 4) and Port Number of the sender

used for Service Discovery.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00559] dThe Format of the IPv6 SD Endpoint Option shall be as

follows:

• Length [uint16]: Shall be set to 0x0015.

• Type [uint8]: Shall be set to 0x26.

• Discardable Flag [1 bit]: Shall be set to 0.

• Bit 1 to bit 7 are reserved and shall be 0.

• IPv6-Address [uint128]: Shall transport the unicast IP-Address of SOME/IP-SD

as 16 Bytes.

• Reserved [uint8]: Shall be set to 0x00.

• Transport Protocol (L4-Proto) [uint8]: Shall be set to the transport layer protocol

of SOME/IP-SD (currently: 0x11 UDP).

41 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Transport Protocol Port Number (L4-Port) [uint16]: Shall be set to the transport

layer port of SOME/IP-SD (currently: 30490).

c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

[PRS_SOMEIPSD_00837] dThe IPv6 SD Endpoint Option shall only be included if

the SOME/IP-SD message is transported over IPv6.c(RS_SOMEIPSD_00006, RS_-

SOMEIPSD_00010)

[PRS_SOMEIPSD_00838] dIf more than one IPv6 SD Endpoint Option is received,

only the first one shall be processed and all further IPv6 SD Endpoint Options shall be

ignored.c(RS_SOMEIPSD_00006, RS_SOMEIPSD_00010)

5.1.2.5 Service Entries

Find Service Entry

[PRS_SOMEIPSD_00350] dThe Find Service entry type shall be used for finding ser-

vice instances and shall only be sent if the current state of a service is unknown (no

current Service Offer was received and is still valid).c(RS_SOMEIPSD_00008, RS_-

SOMEIPSD_00021)

[PRS_SOMEIPSD_00351] dFind Service entries shall set the entry fields in the follow-

ing way:

• Type shall be set to 0x00 (FindService).

• Service ID shall be set to the Service ID of the service that shall be found.

• Instance ID shall be set to 0xFFFF, if all service instances shall be returned. It

shall be set to the Instance ID of a specific service instance, if just a single service

instance shall be returned.

• Major Version shall be set to 0xFF, that means that services with any version shall

be returned. If set to value different than 0xFF, services with this specific major

version shall be returned only.

• Minor Version shall be set to 0xFFFF FFFF, that means that services with any

version shall be returned. If set to a value different to 0xFFFF FFFF, services

with this specific minor version shall be returned only.

• TTL is not used for FindService entries and can be set to an arbitrary value.The

field is only defined for backward compatibility, and the value shall be ignored by

the receiver of the message.

c(RS_SOMEIPSD_00008, RS_SOMEIPSD_00021)

Note: It is expected that the Major Version on client side is configured to a specific

value in normal operation since the client should look for an specific interface version.

Different Major Versions are not compatible to each other.

42 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00528] dA sender shall not reference Endpoint Options nor Mul-

ticast Options in a Find Service Entry.c(RS_SOMEIPSD_00008, RS_SOMEIPSD_-

00025)

[PRS_SOMEIPSD_00529] dA receiver shall ignore Endpoint Options and Multicast

Options in a Find Service Entry.c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00530] dOther Options (neither Endpoint nor Multicast Options),

shall still be allowed to be used in a Find Service Entry.c(RS_SOMEIPSD_00013,

RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00825] dWhen receiving a FindService Entry the Service ID, In-

stance ID, Major Version, and Minor Version shall match exactly to the configured val-

ues to identify a Service Instance, except if "any values" are in the Entry (i.e. 0xFFFF

for Service ID, 0xFFFF for Instance ID, 0xFF for Major Version, and 0xFFFFFFFF for

Minor Version.)c()

[PRS_SOMEIPSD_00839] dIf a FindService Entry is received within the Initial Wait

Phase for this Server Service Instance, it shall be ignored.c()

Offer Service Entry

[PRS_SOMEIPSD_00355] dThe Offer Service entry type shall be used to offer a ser-

vice to other communication partners.c(RS_SOMEIPSD_00013)

[PRS_SOMEIPSD_00356] dOffer Service entries shall set the entry fields in the fol-

lowing way:

• Type shall be set to 0x01 (OfferService).

• Service ID shall be set to the Service ID of the service instance offered.

• Instance ID shall be set to the Instance ID of the service instance that is offered.

• Major Version shall be set to the Major Version of the service instance that is

offered.

• Minor Version shall be set to the Minor Version of the service instance that is

offered.

• TTL shall be set to the lifetime of the service instance. After this lifetime the

service instance shall considered not been offered.

• If TTL is set to 0xFFFFFF, the Offer Service entry shall be considered valid until

the next reboot.

• TTL shall not be set to 0x000000 since this is considered to be the Stop Offer

Service Entry.

c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

43 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00357] dOffer Service entries shall always reference either an IPv4

or IPv6 Endpoint Option to signal how the service is reachable.c(RS_SOMEIPSD_-

00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00358] dFor each Transport Layer Protocol needed for the service

(i.e. UDP and/or TCP) an IPv4 Endpoint option shall be added if IPv4 is supported.c

(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00359] dFor each Transport Layer Protocol needed for the service

(i.e. UDP and/or TCP) an IPv6 Endpoint option shall be added if IPv6 is supported.c

(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00826] dWhen receiving the initial OfferService Entry the Service

ID, Instance ID, Major Version and Minor Version shall match exactly to the configured

values to identify a Service Instance, except if "any values" are in the service configu-

ration (i.e. 0xFFFF for Instance ID and 0xFFFFFFFF for Minor Version.)c()

[PRS_SOMEIPSD_00827] dWhen receiving a subsequent OfferService Entry or a

StopOfferService Entry the Service ID, Instance ID, Major Version shall match exactly

to the values in the initial OfferService entry to identify a Service Instance.c()

Stop Offer Service Entry

[PRS_SOMEIPSD_00363] dThe Stop Offer Service entry type shall be used to stop

offering service instances.c(RS_SOMEIPSD_00014)

[PRS_SOMEIPSD_00364] dStop Offer Service entries shall set the entry fields exactly

like the Offer Service entry they are stopping, except:

• TTL shall be set to 0x000000.

c(RS_SOMEIPSD_00014)

[PRS_SOMEIPSD_00840] dA StopOfferService (type 0x01), shall carry, i.e. reference,

the same options as the entries trying to stop.c()

Usage of Options in Entries

[PRS_SOMEIPSD_00583] d

Table 5.1 shall show the SOME/IP-SD Option types in relation to Entry types which are

allowed:

c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00008, RS_SOMEIPSD_00013, RS_-

SOMEIPSD_00014, RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)

Endpoint Multicast Configuration Load Balanc-

ing

FindService 0 0 0-1 0-1

44 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

OfferService 1-2 0 0-1 0-1

StopOffer Service 1-2 0 0-1 0-1

Subscribe Event-

group

0-2 0-1 0-1 0-1

StopSubscribe

Eventgroup

0-2 0-1 0-1 0-1

Subscribe Event-

groupAck

0 0-1 0-1 0-1

Subscribe Event-

groupNack

0 0 0-1 0-1

Table 5.1: Allowed Option Types for Entry Types

5.1.2.6 Endpoint Handling for Services and Events

[PRS_SOMEIPSD_00476] dThe Service Discovery shall overwrite IP Addresses and

Port Numbers with those transported in Endpoint and Multicast Options if the statically

configured values are different from those in these options.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00360] dThe IP addresses and port numbers of the Endpoint

Options shall also be used for transporting events and notification events.c(RS_-

SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00361] dIn case of UDP the endpoint option shall be used for the

source address and the source port of the events and notification events, it is also

the address the client can send method requests to.c(RS_SOMEIPSD_00013, RS_-

SOMEIPSD_00025)

[PRS_SOMEIPSD_00362] dIn case of TCP the endpoint option shall be used for the IP

address and port the client needs to open a TCP connection in order to receive events

using TCP.c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00801] dSOME/IP shall allow services to use UDP and TCP at the

same time.c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00802] dWhich message is sent by which under lying transport pro-

tocol shall be determined by configuration: A Service can use UDP and TCP endpoints

at the same time. But per element of the service it shall to be configured whether TCP

or UDP is used.c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

Note: It needs to be restricted in the configuration which methods and which events

are provided over TCP/UDP. This also means that the same event can not be provided

over TCP and UDP.

Service Endpoints

The referenced Endpoint Options of the Offer Service entries denotes the

45 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• IP Address and Port Numbers the service instance is reachable at the server.

• IP Address and Port Numbers the service instance sends the events from.

[PRS_SOMEIPSD_00480] dEvents of this service instance shall not be sent from any

other Endpoints than those given in the Endpoint Options of the Offer Service entries.c

(RS_SOMEIPSD_00013, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00481] dIf an ECU offers multiple service instances, SOME/IP

messages of these service instances shall be differentiated by the information

transported in the Endpoint Options referenced by the Offer Service entries.c(RS_-

SOMEIPSD_00013, RS_SOMEIPSD_00025)

Eventgroup Endpoints

[PRS_SOMEIPSD_00484] dThe Endpoint Options referenced in the Subscribe Event-

group entries shall also be used to send unicast UDP or TCP SOME/IP events for this

Service Instance.c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

Thus the Endpoint Options referenced in the Subscribe Eventgroup entries are the IP

Address and the Port Numbers on the client side.

[PRS_SOMEIPSD_00486] dTCP events are transported using the TCP connection the

client has opened to the server before sending the Subscribe Eventgroup entry. See

Chapter 5.1.2.4.c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00487] dThe initial events shall be transported using unicast from

Server to Client.c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00488] dSubscribe Eventgroup Ack entries shall reference up to

1 Multicast Option for the Internet Protocol used (IPv4 or IPv6).c(RS_SOMEIPSD_-

00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00489] dThe Multicast Option shall be set to UDP as transport pro-

tocol.c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00490] dThe client shall open the Endpoint specified in the Multi-

cast Option referenced by the Subscribe Eventgroup Ack entry as fast as possible to

not miss multicast events.c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

Example: Figure 5.15 shows an example with the different Endpoint and a Multicast

Option:

• The Server offers the Service Instance on Server UDP-Endpoint SU and Server

TCP-Endpoint ST

• The Client opens a TCP connection

• The Client sends a Subscribe Eventgroup entry with Client UDP-Endpoint CU

(unicast) and a Client TCP-Endpoint CT.

46 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• The Server answers with a Subscr ibe Eventgroup Ack entry with Multicast MU

Then the following operations happen:

• The Client calls a method on the Server

• Request is sent from CU to SU and Response from SU to CU

• For TCP this would be: Request dyn to ST and RESPONSE from ST to CT

• The Server sends a Unicast UDP Event: SU to CU

• The Server sends a Unicast TCP Event: ST to CT

• The Server sends a Multicast UDP Event: SU to MU

Keep in mind that Multicast Endpoints use a Multicast IP Address on the receiver side,

i.e. the client, and TCP cannot be used for Multicast communication.

Figure 5.15: Publish/Subscribe Example for Endpoint Options and the usage of ports

5.1.3 Service Discovery Messages

[PRS_SOMEIPSD_00600] dAll SD Messages shall be sent to SD_PORT.c(RS_-

SOMEIPSD_00001)

47 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00601] dSD_PORT shall be used as the source port for SD Uni-

cast/Multicast Messages.c(RS_SOMEIPSD_00002, RS_SOMEIPSD_00003)

[PRS_SOMEIPSD_00602] dAll unicast SD messages should have SD_PORT as desti-

nation port unless the SD Endpoint Option defines a different port.c(RS_SOMEIPSD_-

00002)

[PRS_SOMEIPSD_00603] dAll SD multicast messages shall be sent using the

SD_MULTICAST_IP.c(RS_SOMEIPSD_00003, RS_SOMEIPSD_00022)

[PRS_SOMEIPSD_00841] dWhen receiving Service Discovery messages, the receiver

shall ignore Entries of unknown type.c()

Using the previously specified header format, different entries and messages consist-

ing of one or more entries can be built. The specific entries and their header layouts

are explained in the following sections.

5.1.3.1 Eventgroup Entry

Subscribe Eventgroup Entry

[PRS_SOMEIPSD_00385] dThe Subscr ibe Eventgroup entry type shall be used to

subscribe to an eventgroup.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00386] dSubscribe Eventgroup entries shall set the entry fields in

the following way:

• Type shall be set to 0x06 (SubscribeEventgroup).

• Service ID shall be set to the Service ID of the service instance that includes the

eventgroup subscribed to.

• Instance ID shall be set to the Instance ID of the service instance that includes

the eventgroup subscribed to.

• Major Version shall be set to the Major Version of the service instance of the

eventgroup subscribed to.

• Eventgroup ID shall be set to the Eventgroup ID of the eventgroup subscribed to.

• TTL shall be set to the lifetime of the subscription.

– If set to 0xFFFFFF, the Subscribe Eventgroup entry shall be considered valid

until the next reboot.

– TTL shall not be set to 0x000000 since this is considered to be the Stop

Offer Service Entry.

• Reserved shall be set to 0x000 until further notice.

48 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Counter shall be used to differentiate between parallel subscribes to the same

eventgroup of the same service (only difference in endpoint). If not used, set to

0x0.

c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00846] dA SubscribeEventgroup entry reference the endpoints (IP

address, port, and protocol) where the client wishes to receive the events. A client

service could subscribe to the same Eventgroup either with a client unicast endpoint

or with a client multicast endpoint:

• If a client subscribes with a client unicast endpoint via an Endpoint Option, the

client announces its desire to receive the events as unicast events transmitted to

the given unicast endpoint.

• If a client subscribes with a client multicast endpoint via an Endpoint Option, the

client announces its desire to receive the events as multicast events transmitted

to the given multicast endpoint.

c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00387] dSubscribeEventgroup entr ies shall reference options ac-

cording to the following rules:

• either up to two IPv4 or up to two IPv6 Endpoint Options (one for UDP, one for

TCP)

• either up to one IPv4 Multicast Option or up to one IPv6 Multicast Option (only

UDP supported)

c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

Note:

This explicitly rules out that a single service instance is offered via IPv4 and IPv6 at the

same time.

The network communication design has to consider the following points:

• If the server uses only IP multicast for event transmission over UDP the Sub-

scribeEventgroup entry does not need to reference a UDP Endpoint Option.

• If the server transmits initial events for an Eventgroup the SubscribeEvent-

group entry shall reference an according Endpoint Option because of

[PRS_SOMEIPSD_00487].

• If a client service subscribes with an Multicast Option (client service multicast

endpoint) and the server transmit initial

[PRS_SOMEIPSD_00828] dWhen receiving a SubscribeEventgroup or StopSub-

scribeEventgroup the Service ID, Instance ID, Eventgroup ID, and Major Version shall

match exactly to the configured values to identify an Eventgroup of a Service Instance.c

(RS_SOMEIPSD_00015, RS_SOMEIPSD_00025)

49 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00810] dIf the server receives a Subscribe Eventgroup entry

without a UDP Endpoint Option (see [PRS_SOMEIPSD_00387]) and the MULTI-

CAST_THRESHOLD for the Eventgroup is not configured with value 1 then Sub-

scribeEventGroupNack shall be sent back to the client.c(RS_SOMEIPSD_00015, RS_-

SOMEIPSD_00025)

Stop Subscribe Eventgroup Entry

[PRS_SOMEIPSD_00388] dThe Stop Subscribe Eventgroup entry type shall be used

to stop subscribing to eventgroups.c(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00389] dStop Subscribe Eventgroup entries shall set the entry

fields exactly like the Subscribe Eventgroup entry they are stopping, except:

• TTL shall be set to 0x000000.

c(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00574] dA Stop Subscribe Eventgroup Entry shall reference the

same options the Subscribe Eventgroup Entry referenced. This includes but is not

limited to Endpoint and Configuration options.c(RS_SOMEIPSD_00017)

Subscribe Eventgroup Acknowledgement (Subscribe Eventgroup Ack) Entry

[PRS_SOMEIPSD_00390] dThe Subscr ibe Eventgroup Acknowledgment entry type

shall be used to indicate that Subscribe Eventgroup entry was accepted.c(RS_-

SOMEIPSD_00015)

[PRS_SOMEIPSD_00391] dSubscribe Eventgroup Acknowledgment entries shall set

the entry fields in the following way:

• Type shall be set to 0x07 (SubscribeEventgroupAck).

• Service ID, Instance ID, Major Version, Eventgroup ID, TTL, Reserved and

Counter shall be the same value as in the Subscr ibe Eventgroup that is being

answered.

c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00392] dSubscr ibe Eventgroup Ack entries referencing events and

notification events that are transported via multicast shall reference an IPv4 Multicast

Option and/or and IPv6 Multicast Option. The Multicast Options state to which Multicast

address and port the events and notification events will be sent to.c(RS_SOMEIPSD_-

00015)

50 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00829] dWhen receiving a SubscribeEventgroupAck or Sub-

scribeEventgroupNack the Service ID, Instance ID, Eventgroup ID, and Major Ver-

sion shall match exactly to the corresponding SubscribeEventgroup Entry to identify

an Eventgroup of a Service Instance.c()

Subscribe Eventgroup Negative Acknowledgement (Subscribe Eventgroup

Nack) Entry

[PRS_SOMEIPSD_00393] dThe Subscribe Eventgroup Negative Acknowledgment en-

try type shall be used to indicate that Subscr ibe Eventgroup entry was NOT accepted.c

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00394] dSubscribe Eventgroup Negative Acknowledgment entries

shall set the entry fields in the following way:

• Type shall be set to 0x07 (SubscribeEventgroupAck).

• Service ID, Instance ID, Major Version, Eventgroup ID, Counter, and Reserved

shall be the same value as in the Subscribe that is being answered.

• The TTL shall be set to 0x000000.

c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00566] dReasons to not accept a Subscribe Eventgroup include

(but are not limited to):

• Combination of Service ID, Instance ID, Eventgroup ID, and Major Version is un-

known

• Required TCP-connection was not opened by client

• Problems with the references options occurred

• Resource problems at the Server

• Security association not yet established

c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00527] dWhen the client receives a SubscribeEventgroupNack as

answer on a SubscribeEventgroup for which a TCP connection is required, the client

shall check the TCP connection and shall restart the TCP connection if needed.c(RS_-

SOMEIPSD_00015)

Note: [PRS_SOMEIPSD_00527] involves checking the state of the network security

protocol

Rational:

The server might have lost the TCP connection and the client has not.

Checking the TCP connection might include the following:

51 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Checking whether data is received for e.g. other Eventgroups.

• Sending out a Magic Cookie message and waiting for the TCP ACK.

• Reestablishing the TCP connection.

[PRS_SOMEIPSD_00842] dThe following overview table shows to which value the

Type field and the TTL field have to be set:c(RS_SOMEIPSD_00015)

TTL > 0 TTL = 0

Type 0x00 0x04 0x00 0x04

0x00 FindService

0x01 OfferService StopOfferService

0x02 SubscribeEventgroup StopSubscribeEventgroup

0x03 SubscribeEventgroupAck SubscribeEventgroupNack

Table 5.2: Overview of currently supported Entry Types

5.1.4 Service Discovery Communication Behavior

[PRS_SOMEIPSD_00800] dSOME/IP Service Discovery shall reduce the number of

Service Discovery messages by packing entries together, if they can be sent at the

same time. E.g.:

• Multiple entries of different service instances

• Multiple entries of different types (e.g. Offer entries, answers of Subscribed

EventGroup entries ... a.s.o.)

c(RS_SOMEIPSD_00025)

5.1.4.1 Startup Behavior

[PRS_SOMEIPSD_00395] dFor each Service Instance the Service Discovery shall

have at least these three phases in regard to sending entries:

• Initial Wait Phase

• Repetition Phase

• Main Phase

c(RS_SOMEIPSD_00025)

Note:

An actual implemented state machine will need more than just states for these three

phases. E.g. local services can be still down and remote services can be already

known (no finds needed anymore).

[PRS_SOMEIPSD_00397] dThe service discovery shall enter the Initial Wait Phase for

a client service instance when the link on the interface needed for this service instance

52 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

is up and the client service is requested by the application.c(RS_SOMEIPSD_00025,

RS_SOMEIPSD_00012)

[PRS_SOMEIPSD_00133] dThe service discovery shall enter the Initial Wait Phase for

a server service instance when the link on the interface needed for this service instance

is up and the server service is available.c(RS_SOMEIPSD_00025, RS_SOMEIPSD_-

00012)

Note:

It is possible that the link is up but the service is not yet available on server side

Systems has started means here the needed applications and possible external sen-

sors and actuators as well. Basically the functionality needed by this service instance

has to be ready to offer a service and finding a service is applicable after some appli-

cation requires it.

[PRS_SOMEIPSD_00399] dThe Service Discovery shall wait based on the INI-

TIAL_DELAY after entering the Initial Wait Phase and before sending the first mes-

sages for the Service Instance.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00400] dINITIAL_DELAY shall be defined as a minimum and a

maximum delay.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00401] dThe wait time shall be determined by choosing a random

value between the minimum and maximum of INITIAL_DELAY.c(RS_SOMEIPSD_-

00025)

[PRS_SOMEIPSD_00804] dThe Service Discovery shall use the same random value,

if ClientService and ServerService reference the same ClientServiceTimer and Ser-

verServiceTimer, respectively, and if it its ensured that the referencing ClientService

and ServerService, respectively, are requested and released in the same point in time.c

(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00805] dThe Service Discovery shall use different random values

per ClientService and ServerService, if the ClientServices and ServerService refer-

encing their own ClientServiceTimer and ServerServiceTimer, respectively. Thus, if a

ClientService or ServerSer vice enters the Initial Wait Phase, they shall use an individ-

ual calculated random value within the Initial Wait Phase.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00404] dAfter sending the first message the Repetition Phase of

this Service Instance/these Service Instances is entered.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00405] dThe Service Discovery shall wait in the Repetitions Phase

based on REPETITIONS_BASE_DELAY.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00406] dAfter each message sent in the Repetition Phase the de-

lay is doubled.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00407] dThe Service Discovery shall send out only up to REPETI-

TIONS_MAX entries during the Repetition Phase.c(RS_SOMEIPSD_00025)

53 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00408] dSending Find entr ies shall be stopped after receiving the

corresponding Offer entries by jumping to the Main Phase in which no Find entries are

sent.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00409] dIf REPETITIONS_MAX is set to 0, the Repetition Phase

shall be skipped and the Main Phase is entered for the Service Instance after the Initial

Wait Phase.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00410] dAfter the Repetition Phase the Main Phase is being en-

tered for a Service Instance.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00411] dAfter entering the Main Phase, the provider shall wait

1*CYCLIC_OFFER_DELAY before sending the first offer entry message.c(RS_-

SOMEIPSD_00025)

[PRS_SOMEIPSD_00412] dIn the Main Phase Offer Messages shall be sent cyclically

if a CYCLIC_OFFER_DELAY is configured.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00413] dAfter a message for a specific Service Instance the Ser-

vice Discovery waits for 1*CYCLIC_OFFER_DELAY before sending the next message

for this Service Instance.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00415] dFor Find entries (Find Service and Find Eventgroup) no

cyclic messages are allowed in Main Phase.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00582] dSubscribe EventGroup Entries shall be tr iggered by Offer

entries, which are sent cyclically.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00416] dExample:

Initial Wait Phase:

• Wait for random_delay in Range(INITIAL_DELAY_MIN, _MAX)

• Send message (Find Service and Offer Service entries)

Repetition Phase (REPETITIONS_BASE_DELAY=100ms, REPETITIONS_MAX=2):

• Wait 2

∗ 100ms

• Send message (Find Service and Offer Service entries)

• Wait 2

∗ 100ms

• Send message (Find Service and Offer Service entries)

Main Phase:

• Server:

– as long message is active and CYCLIC_OFFER_DELAY is defined

∗ Wait CYCLIC_OFFER_DELAY

∗ Send message (Offer Service entries)

54 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Client:

– as long as offer service messages are received, Subscribe Eventgroup mes-

sage is sent

c(RS_SOMEIPSD_00025)

5.1.4.2 Server Answer Behavior

[PRS_SOMEIPSD_00417] dThe Service Discovery shall delay answers to entries that

were received in multicast SOME/IP-SD messages using the configuration item RE-

QUEST_RESPONSE_DELAY. This is valid for the following two cases:

• Offer entry (unicast or multicast) after received find entry (multicast)

• Subscribe entry (unicast) after received offer entry (multicast)

c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00419] dThe REQUEST_RESPONSE_DELAY shall not apply if

unicast messages are answered with unicast messages.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00420] dREQUEST_RESPONSE_DELAY shall be specified by a

minimum and a maximum.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00421] dThe actual delay shall be randomly chosen between mini-

mum and maximum of REQUEST_RESPONSE_DELAY.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00422] dFor basic implementations all Find Service entries shall

be answered with Offer Service entries transported using unicast.c(RS_SOMEIPSD_-

00025)

[PRS_SOMEIPSD_00423] dFor optimization purpose the following behaviors shall be

supported as option:

• Find messages received with the Unicast Flag set to 1 in main phase, shall

be answered with a unicast response if the latest offer was sent less than 1/2

CYCLIC_OFFER_DELAY ago.

• Find messages received with the Unicast Flag set to 1 in main phase, shall

be answered with a multicast RESPONSE if the latest offer was sent 1/2

CYCLIC_OFFER_DELAY or longer ago.

c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00843] dEntries received with the unicast flag set to 0, shall not be

answered with unicast but ignored.c(RS_SOMEIPSD_00025)

55 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

5.1.4.3 Shutdown Behavior

[PRS_SOMEIPSD_00427] dWhen a server service instance of an ECU is in the Rep-

etition and Main Phase and is being stopped, a Stop Offer Service entry shall be sent

out.c(RS_SOMEIPSD_00017, RS_SOMEIPSD_00012)

[PRS_SOMEIPSD_00751] dWhen the link goes down for a server service instance in

the Initial Wait Phase, Repetition Phase or Main Phase, the service discovery shall

enter the Down Phase and reenter into Initial Wait Phase when the link is up again and

the service is still available.c(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00752] dWhen the link goes down for a client service instance in

the Initial Wait Phase, Repetition Phase or Main Phase, the service discovery shall

enter the Down Phase and reenter into Initial Wait Phase when the link is up again and

the service is still available..c(RS_SOMEIPSD_00017)

[PRS_SOMEIPSD_00428] dWhen a server sends out a Stop Offer Service entry all

subscriptions for this service instance shall be deleted on the server side.c(RS_-

SOMEIPSD_00017)

[PRS_SOMEIPSD_00429] dWhen a client receives a Stop Offer Service entry all

subscriptions for this service instance shall be deleted on the client side.c(RS_-

SOMEIPSD_00017)

[PRS_SOMEIPSD_00430] dWhen a client receives a Stop Offer Service entry, the

client shall not send out Find Service entries but wait for Offer Service entry or

change of status (application, network management, Ethernet link, or similar).c(RS_-

SOMEIPSD_00017)

[PRS_SOMEIPSD_00431] dWhen a client service instance of an ECU is in the Main

Phase and is being stopped (i.e. the service instance is released), the SD shall

send out Stop Subscribe Eventgroup entries for all subscribed Eventgroups.c(RS_-

SOMEIPSD_00017)

[PRS_SOMEIPSD_00432] dWhen the whole ECUs is being shut down Stop Offer Ser-

vice entries shall be sent out for all service entries and Stop Subscribe Eventgroup

entries for Eventgroups.c(RS_SOMEIPSD_00017)

5.1.4.4 State Machines

[PRS_SOMEIPSD_00433] dIn this section the state machines of the client and server

are shown.c(RS_SOMEIPSD_00025)

[PRS_SOMEIPSD_00434] dSOME/IP Service State Machine Server is described as

follows:

States inside SD Server State Machine(Service) are defined as follows:

• SD Server State Machine(Service)

56 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

– Not Ready

– Ready

∗ Initial Wait Phase

· Timer Set

∗ Repetition Phase

· Timer Set

∗ Main Phase

· Timer Set

Initial entry points of SD Server State Machine(Service) are inside the follow-

ing states:

• SD Server State Machine(Service)

– Ready

∗ Initial Wait Phase

∗ Repetition Phase

∗ Main Phase

Transitions inside SD Server State Machine(Service) are defined as follows:

FROM entry point SD Server State Machine(Service)

TO Not Ready

WITH [ifstatus!=up_and_configured or service-status==down]

FROM entry point SD Server State Machine(Service)

TO Not Ready

WITH [ifstatus==up_and_configured or service-status==up]

FROM Not Ready

TO Ready

WITH if-status-changed() or service-status-changed() [ifsta-

tus==up_and_configured and service-status==up]

FROM Ready

TO Not Ready

WITH if-status-changed [ifstatus!=up_and_configured] /clearAll-

Timers()

FROM Ready

TO Not Ready

57 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

WITH service-status==down /clearAllTimers() send(StopOfferSer-

vice)

FROM TimerSet

OF Initial Wait Phase

TO Repetition Phase

WITH Timer expired /send(OfferService)

FROM TimerSet

OF Repetition Phase

TO TimerSet

OF Repetition Phase

WITH receive(FindService) /waitAndSend(OfferService) ResetTimer

()

FROM TimerSet

OF Repetition Phase

TO TimerSet

OF Repetition Phase

WITH Timer expired [run<REPETITIONS_MAX] /send(OfferService)

run++ setTimer((2

run)

REPETITIONS_BASE_DELAY

FROM TimerSet

OF Repetition Phase

TO Main Phase

WITH Timer expired [run==REPETITIONS_MAX]

FROM entry point Ready

TO Initial Wait Phase

FROM entry point Initial Wait Phase

TO Timer Set

OF Initial Wait Phase

WITH SetTimerInRange(INITIAL_DELAY_MIN,INITIAL_DELAY_MAX)

FROM entry point Repetition Phase

TO Timer Set

OF Repetition Phase

WITH [REPETITIONS_MAX>0] /run=0 setTimer((2

run)

REPETI-

TIONS_BASE_DELAY)

FROM entry point Repetition Phase

TO Main Phase

58 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

WITH [REPETITIONS_MAX==0]

FROM entry point Main Phase

TO Timer Set

OF Main Phase

WITH /setTimer(CYCLIC_ANNOUNCE_DELAY) send(OfferService)

FROM Timer Set

OF Main Phase

TO Timer Set

OF Main Phase

WITH Timer expired /setTimer(CYCLIC_ANNOUNCE_DELAY) send(Of-

ferService)

FROM Timer Set

OF Main Phase

TO Timer Set

OF Main Phase

WITH receive(FindService) /waitAndSend(OfferService) resetTimer

()

c(RS_SOMEIPSD_00025)

Note: Graphical information of the SOME/IP Service State Machine Server is shown in

Figure 5.16

59 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

stm SD Serv er State Machine (Serv ices)

SD Serv er State Machine (Serv ices)

Initial

Not Ready

Ready

Initial Wait Phase

Repetition Phase

Main Phase

Initial

Timer set

Initial

Timer set

Initial

Timer set

Timer expired [run<REPETITIONS_MAX]

/send(OfferService)

run++

setT imer((2^run)*REPETITIONS_BASE_DELAY)

[ifstatus==up_and_configured

and service-status==up]

if-status-changed() or servi ce-status-changed()

[ifstatus==up_and_configured and

service-status==up]

SetTimerInRange(INITIAL_DELAY_MIN,

INITIAL_DELAY_MAX)

Timer expired

/send(OfferService)

[ifstatus!=up_and_configured

or servi ce-status==down]

[REPETITIONS_MAX>0]

/run=0

setTimer((2^run)*REPETITIONS_BASE_DELAY)

service-status==down

/clearAl lTimers()

send(StopOfferService)

Timer expi red

[run==REPETITIONS_MAX]

receive(FindService)

/wai tAndSend(OfferService)

resetTi mer()

/setTimer(CYCLIC_ANNOUNCE_DELAY)

send(OfferService)

Timer expi red

/setTimer(CYCLIC_ANNOUNCE_DELAY)

send(OfferService)

if-status-changed [i fstatus!=up_and_configured]

/clearAllT imers()

receive(FindServi ce)

/waitAndSend(OfferService)

ResetTimer()

[REPET ITIONS_MAX==0]

Figure 5.16: SOME/IP Service State Machine Server

[PRS_SOMEIPSD_00435] dSOME/IP Service State Machine Client is described as

follows:

60 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

States inside SD Client State Machine(Service) are defined as follows:

• SD Client State Machine(Service)

– Not Requested

∗ Service Not Seen

∗ Service Seen

– Requested_but_not_ready

– Main

∗ Service Ready

∗ Stopped

– Searching for Service

∗ Initial Wait Phase

· Timer Set

∗ Repetition Phase

· Timer Set

Initial entry points of SD Client State Machine(Service) are inside the follow-

ing states:

• SD Client State Machine(Service)

– Not Requested

• Searching for Service

– Initial Wait Phase

– Repetition Phase

Transitions inside SD Client State Machine(Service) are defined as follows:

FROM entry point SD Client State Machine(Service)

TO Not Requested

WITH [Service Not Requested]

FROM entry point SD Client State Machine(Service)

TO Requested_but_not_ready

WITH Service Not Requested and ifstatus!=up_and_configured

FROM entry point SD Client State Machine(Service)

TO Searching for Service

61 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

WITH Service Requested and ifstatus==up_and_configured

FROM entry point Not Requested TO Service Not Seen

FROM Not Requested TO Requested_but_not_ready

WITH InternalServiceRequest [ifstatus!=up_and_configured]

FROM Service Not Seen

TO Service Seen

WITH receive(OfferService) /setTimer(TTL)

FROM Repetition Phase

TO Stopped

WITH Repetition Expired

FROM Repetition Phase

TO Stopped

WITH receive(StopOfferService)

FROM Stopped

TO Service Not Seen

WITH [ServiceNotRequired]

FROM Service Seen

TO Service Not Seen

WITH if-status-changed() [ifstatus!=up_and_configured]

FROM Service Seen

TO Service Not Seen

WITH Timer expired (TTL)

FROM Repetition Phase

TO Stopped

WITH Repetition Expired

FROM Service Seen

TO Service Not Seen

WITH receive(StopServiceOffer)

62 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

FROM Service Seen

TO Service Seen

FROM Service Seen

TO Service Ready

WITH InternalServiceRequest [ifstatus==up_and_configured]

FROM Service Ready

TO Service Seen

WITH [ServiceNotRequest]

FROM Service Ready

TO Service Ready

WITH receive(OfferService) /resetTimer(TTL)

FROM Service Ready

TO Stopped

WITH receive(OfferService) /chancelTimer(TTL)

FROM Stopped

TO Service Ready

WITH receive(OfferService) /resetTimer(TTL)

FROM Service Ready

TO Searching for Service

WITH Timer expired (TTL)

FROM Searching for Service

TO Service Ready

WITH receive(OfferService) /setTimer(TTL)

FROM Searching for Service

TO Requested_but_not_ready

WITH if-status-changed() [ifstatus!=up_and_configured] /cancel-

Timer(TTL)

FROM Requested_but_not_ready

TO Searching for Service

WITH if-status-changed() [ifstatus!=up_and_configured]

63 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

FROM entry point Searching for Service

TO Initial Wait Phase

FROM entry point Initial Wait Phase

TO Timer Set

OF Initial Wait Phase

WITH /setTimerInRange(INITIAL_DELAY_MIN, INITIAL_DELAY_MAX)

FROM Timer Set

OF Initial Wait Phase

TO Repetition Phase

WITH TimerExpired /send(FindService)

FROM entry point Repetition Phase

TO Timer Set

OF Repetition Phase

WITH [REPETITONS_MAX>0] /run=0 setTimer((2

run)

REPETI-

TIONS_BASE_DELAY)

FROM Timer Set

OF Repetition Phase

TO Timer Set

OF Repetition Phase

FROM Not Requested

TO Requested_but_not_ready

WITH InternalServiceRequest [ifstatus!=up_and_configured]

c(RS_SOMEIPSD_00025)

Note: Graphical information of the SOME/IP Service State Machine Client is shown in

Figure 5.17

64 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Figure 5.17: SOME/IP Service State Machine Client

5.1.4.5 SOME/IP-SD Mechanisms and Errors

In this section SOME/IP-SD in cases of errors (e.g. lost or corrupted packets) is dis-

cussed. This is also be understood as rationale for the mechanisms used and the

configuration possible.

Soft State Protocol: SOME/IP-SD was designed as soft state protocol, that means that

entries come with a lifetime and need to be refreshed to stay valid (setting the TTL to

the maximum value shall turn this off).

65 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Initial Wait Phase:

The Initial Wait Phase was introduced for two reasons: deskewing events of starting

ECUs to avoid traffic bursts and allowing ECUs to collect multiple entries in SD mes-

sages.

Repetition Phase:

The Repetition Phase was introduced to allow for fast synchronization of clients and

servers. If the clients startup later, it will find the server very fast. And if the server

starts up later, the client can be found very fast. The Repetition Phase increases the

time between two messages exponentially to avoid that overload situations keep the

system from synchronization.

Main Phase:

In the Main Phase the SD tries to stabilize the state and thus decreases the rate of

packets by sending no Find Services anymore and only offers in the cyclic interval

(e.g. every 1s).

Request-Response-Delay:

SOME/IP-SD shall be configured to delay the answer to entries in multicast messages

by the Request-Response-Delay. This is useful in large systems with many ECUs.

When sending a SD message with many entries in it, a lot of answers from different

ECUs arrive at the same time and put large stress on the ECU receiving all these

answers.

66 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

5.1.4.6 Error Handling

Figure 5.18: - SOME/IP-SD Error Handling

67 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Figure 5.18 shows a simplified process for the error handling of incoming SOME/IP-SD

messages.

[PRS_SOMEIPSD_00125] dCheck that at least enough bytes for an empty SOME/IP-

SD message are present, i.e the message is at least 12 Bytes long. If the check fails,

the message shall be discarded without further actions.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00126] dIf the Service ID of a received entry is not known, the entry

shall be ignored.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00127] dIf the Instance ID of a received entry is not known, the

entry shall be ignored.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00128] dIf the Major Version of a received entry is not known, the

entry shall be ignored.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00129] dIf the Eventgroup ID of a received entry is not known,

the entry shall be ignored. This is only applicable to eventgroup entries.c(RS_-

SOMEIPSD_00019)

[PRS_SOMEIPSD_00803] dIf the length of the Entries Array has an invalid size (i.e.

the entries array would exceed the message size), the message shall be discarded

without further actions.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00130] dCheck the referenced Options of each received entry:

• The referenced options exist.

• The entry references all required options (e.g. a provided eventgroup that uses

unicast requires a unicast endpoint option in a received Subscribe Eventgroup

entry).

• The entry only references supported options (e.g. a required eventgroup that

does not support multicast data reception does not support multicast endpoint

options in a Subscribe Eventgroup ACK entry).

• There are no conflicts between the options referenced by an entry (i.e. two op-

tions of same type with contradicting content).

• The Type of the referenced Option is known or the discardable flag is set to 1.

• The Type of the referenced Option is allowed for the entry

[PRS_SOMEIPSD_00583] or discardable flag is set to 1.

• The Length of the referenced Option is consistent to the Type of the Option.

• An Endpoint Option has a valid L4-Protocol field.

• The Option is valid (e.g. a multicast endpoint option shall use a multicast IP

address).

c(RS_SOMEIPSD_00019)

68 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Note:

If an entry references an option that is known by the Service Discovery implementa-

tion but not required by the service (e.g. an Offer references a TCP and UDP option

and the client uses only UDP, or a Subscribe Eventgroup entry references a UDP end-

point option but the server uses only multicast event transmission), the entry shall be

processed.

[PRS_SOMEIPSD_00131] dCheck if the TCP connection is already present (only ap-

plicable, if TCP is configured for Eventgroup and Subscribe Eventgroup entry was re-

ceived)c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00852] dCheck if a security association is already established.c

(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00132] dCheck if enough resources are left (e.g. Socket Connec-

tions)c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00232] d

If the checks in [PRS_SOMEIPSD_00130] fail for a received Find entry, the entry shall

be ignored, except when Endpoint or Multicast Options are referenced, in which case

only the Options shall be ignored according to [PRS_SOMEIPSD_00529].

c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00233] dIf the checks in [PRS_SOMEIPSD_00130] fail for a re-

ceived Offer entry, the entry shall be ignored.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00234] dIf the checks in [PRS_SOMEIPSD_00130],

[PRS_SOMEIPSD_00131], [PRS_SOMEIPSD_00832], [PRS_SOMEIPSD_00852] or

[PRS_SOMEIPSD_00132] fail for a received Subscribe Eventgroup entry, a Subscribe

Eventgroup NACK entry shall be sent.

c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00235] dIf the checks in [PRS_SOMEIPSD_00130] or

[PRS_SOMEIPSD_00132] fail for a received Subscribe Eventgroup ACK entry,

the entry shall be processed, but the subscription shall not be considered as

successful.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00231] dOptions that are referenced by an entry shall be ignored

if:

• The Option Type is not known (i.e. not yet specified, or not supported by the

receiver) and the discardable flag is set to 1.

• The option is redundant (i.e. another option of the same type and same content

is referenced by this entry).

• The option is not required (e.g. a provided eventgroup that uses only multicast

does not require a unicast endpoint option in a received Subscr ibe Eventgroup

entry, though it is still allowed).

69 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00844] dIf the two Configuration Options have conflicting items

(same name), all items shall be handled. There shall be no attempt been made to

merge duplicate items.c(RS_SOMEIPSD_00019)

[PRS_SOMEIPSD_00832] dCheck for a provided service instance which requires a

secure connection if on reception of a subscribe the security association for the corre-

sponding connection is already established.c(RS_SOMEIPSD_00019)

5.1.5 Non-SOME/IP protocols with SOME/IP-SD

Besides SOME/IP other communication protocols are used within the vehicle; e.g. for

Network Management, Diagnosis, or Flash Updates. Such communication protocols

might need to communicate a service instance or have eventgroups as well.

[PRS_SOMEIPSD_00437] dFor Non-SOME/IP protocols (the application protocol itself

doesn’t use SOME/IP but it is published over SOME/IP SD) a special Service-ID shall

be used and further information shall be added using the configuration option:

• Service-ID shall be set to 0xFFFE (reserved)

• Instance-ID shall be used as described for SOME/IP services and eventgroups.

• The Configuration Option shall be added and shall contain exactly one entry with

key "otherserv" and a configurable non-empty value that is determined by the

system department.

c(RS_SOMEIPSD_00004)

[PRS_SOMEIPSD_00438] dSOME/IP services shall not use the otherserv-string in the

Configuration Option.c(RS_SOMEIPSD_00004)

[PRS_SOMEIPSD_00439] dFor Find Service/Offer Service/Request Service entries

the otherserv-String shall be used when announcing non-SOME/IP service instances.c

(RS_SOMEIPSD_00004)

[PRS_SOMEIPSD_00440] d

Example for valid otherserv-string: "otherserv=internaldiag".

Example for an invalid otherserv-string: "otherserv".

Example for an invalid otherserv-string: "otherserv=".c(RS_SOMEIPSD_00004)

70 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Example:

Figure 5.19: SOME/IP-SD Example PDU for Non-SOME/IP-SD

71 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

5.1.6 Publish/Subscribe with SOME/IP and SOME/IP-SD

Note: In contrast to the SOME/IP request/response mechanism there may be cases in

which a client requires a set of parameters from a server, but does not want to request

that information each time it is required. These are called notifications and concern

events and fields.

[PRS_SOMEIPSD_00443] dAll clients needing events and/or notification events shall

RS_SOMEIPSD_00014, RS_SOMEIPSD_00015, RS_SOMEIPSD_00016)

The Notification Interaction sequence is as shown below.

Client Server

SOME/IP-SD: SubscribeEventgroup ()

SOME/IP: Event()

SOME/IP-SD: SubscribeEventgroupAck ()

Figure 5.20: Notification interaction

This feature is comparable but NOT identical to the MOST notification mechanism.

[PRS_SOMEIPSD_00446] dWith the SOME/IP-SD entry Offer Service the server of-

fers to push notifications to clients; thus, it shall be used as trigger for Subscrip-

tions.c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00014, RS_SOMEIPSD_00015,

RS_SOMEIPSD_00016)

[PRS_SOMEIPSD_00449] dEach client shall respond to a SOME/IP-SD Offer Service

entry from the server with a SOME/IP-SD Subscribe Eventgroup entry as long as the

client is still interested in receiving the notifications/events of this eventgroup.

If the client is able to reliably detect the reboot of the server using the SOME/IP-SD

messages reboot flag, the client may choose to only answer Offer Service messages

after the server reboots if configured to do so (TTL set to maximum value). The client

make sure that this works reliable even when the SOME/IP-SD messages of the server

are lost.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00703] dThe client shall explicitly request Initial Events for field

notifier by sending a Stop Subscribe Eventgroup entry and a Subscribe Eventgroup

72 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

entry in the same SOME/IP-SD message, if it has no active subscription to the Event-

group(field and not pure event).(see [PRS_SOMEIPSD_00463])c(RS_SOMEIPSD_-

00015)

[PRS_SOMEIPSD_00811] dIt is not allowed to request initial values of events upon

subscriptions (pure event and not field).c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00704] dIf the client sends out additional Subscribe Eventgroup

entries and the TTL of the previous Subscribe has not expired, then the client shall not

request Initial Events.c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00020)

Reasons for the client to explicitly request Initial Events (see

[PRS_SOMEIPSD_00463]) include but are not limited to:

• The client is currently not subscribed to the Eventgroup.

• The client has seen a link-down/link-up after the last Subscribe Eventgroup entry.

• The client has not received a Subscribe Eventgroup Ack after the last regular

Subscribe Eventgroup

• The client has detected a Reboot of the Server of this Services

[PRS_SOMEIPSD_00570] dIf the client subscribes to two or more eventgroups includ-

ing one or more identical events or fields, the server shall not send duplicated events or

notification events for the field. This does mean regular events and not initial events.c

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00450] dPublish/Subscribe with link loss at client side is described

as follows:

1. No prior registrations + Client subscribes

(a) Server: OfferService()

(b) Client: SubscribeEventgroup[Session ID=x, Reboot=0]

(d) Server: SubscribeEventgroupAck + Events()

2. Link loss at client side

(a) Client: linkDown()

(b) Client: deleteEntries()

3. Client subscribes again, Client Reboot detected

(a) Server: OfferService()

(b) Client: SubscribeEventgroup[Session ID=1, Reboot=1]

73 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

(d) Server Subscr ibeEventgroupAck + Events()

c(RS_SOMEIPSD_00015)

Note: Description is also shown in Figure 5.21.

Figure 5.21: Publish/Subscribe with link loss at client (figure ignoring timings)

Note: The server sending Offer Service entries as implicit Publishes has to keep state

of Subscribe Eventgroup messages for this eventgroup instance in order to know if

notifications/events have to be sent.

[PRS_SOMEIPSD_00452] dA client shall deregister from a server by sending a

SOME/IP-SD Subscribe Eventgroup message with TTL=0 (Stop Subscribe Eventgroup

see [PRS_SOMEIPSD_00389]).c(RS_SOMEIPSD_00017, RS_SOMEIPSD_00020)

74 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00453] d

Publish/Subscribe Registration/Deregistration behavior is described as follows:

1. Client 1 subscribes

(a) Server: OfferService() to Client 1 and Client 2

(b) Client 1: SubscribeEventgroup()

(d) Server: SubscribeEventgroupAck + Events() to Client 1

2. Client 2 subscribes

(a) Client 2: SubscribeEventgroup()

(b) Server: updateRegistration()

3. Client 2 stops subscription

(a) Client 2: StopSubscribeEventgroup()

(b) Server: updateRegistration()

4. Client 1 remains registered

c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00017)

Note: Description is also shown in Figure 5.22.

75 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

sd SEQ-Registration-Deregistration

Server Client 2Client 1

OfferService()

SubscribeEventgroup()

updateRegistration()

SubscribeEventgroupAck + Events()

Event()

SubscribeEventgroup()

updateRegistration()

SubscribeEventgroupAck + Events()

Event()

StopSubscribeEventgroup()

updateRegistration()

Event()

Figure 5.22: Publish/Subscribe Registration/Deregistration behavior (figure ignoring

timings)

[PRS_SOMEIPSD_00454] dThe SOME/IP-SD on the server shall delete the subscrip-

tion, if a relevant SOME/IP error occurs after sending an event or notification event.c

(RS_SOMEIPSD_00017, RS_SOMEIPSD_00019)

The error includes but is not limited to not being able to reach the communication

partner and errors of the TCP connection.

[PRS_SOMEIPSD_00457] d

Publish/Subscribe with link loss at server is described as follows:

1. No prior registrations + Client subscribes

(a) Server: OfferService()

76 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

(b) Client: SubscribeEventgroup()

(d) Server: SubscribeEventgroupAck + Events()

2. Link loss at server side

(a) Client: linkDown()

(b) Client: deleteRegistrations()

3. Server offers again, Server Reboot detected by client

(a) Server: OfferService()[Session ID=1, Reboot=1]

(b) Client: SubscribeEventgroup()

(d) Server Subscr ibeEventgroupAck + Events()

c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00015)

Note: Description is also shown in Figure 5.23

77 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

sd SEQ-LinkLossServ er

ClientServer

No registration.

Reboot

detected!

OfferService()

SubscribeEventgroup()

updateRegistration()

SubscribeEventgroupAck + Events()

linkDown()

deleteRegistrations()

linkUp()

OfferService() [Session ID=1, Reboot=1]

SubscribeEventgroup()

updateRegistration()

SubscribeEventgroupAck + Events()

Figure 5.23: Publish/Subscribe with link loss at server (figure ignoring timings)

[PRS_SOMEIPSD_00461] dThe client shall open a TCP connection to the server be-

fore sending the Subscribe Eventgroup entry if the Service is offered over TCP and

the client requests an Eventgroup over TCP according to the configuration.c(RS_-

SOMEIPSD_00015)

[PRS_SOMEIPSD_00830] dA client which wants to subscribe to a service which de-

mands a security association shall start (if not already started) to establish the security

and wait until the security association is established. The client shall send a Sub-

scribeEventgroup entry for this service after the security association is established.c

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00831] dFor security associations which demand that only one par-

ticipant is allowed to start establishing the security association (like (d)TLS), each ECU

shall use different end points for server services and client service to ensure that the

78 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

ECU is acting for each secured connection either as a client (which shall start estab-

lishing the security association) or as a server.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00462] dAfter a client has sent a Subscribe Eventgroup entry the

server shall send a Subscribe Eventgroup Ack entry.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00463] dThe client shall wait for the Subscribe Eventgroup Ack

entry acknowledging a Subscribe Eventgroup entry. If this Subscribe Eventgroup Ack

entry does not arrive before the next Subscribe Eventgroup entry is sent, the client

shall do the following:

• Send a Stop Subscribe Eventgroup entry and a Subscribe Eventgroup entry in

the same SOME/IP-SD message the Subscribe Eventgroup entry would have

been sent with

c(RS_SOMEIPSD_00015) Note:

This behavior exists to cope with short durations of communication loss, so new Initial

Events are triggered to lower the effects of the loss of messages.

[PRS_SOMEIPSD_00577] dThe requirement [PRS_SOMEIPSD_00463] shall not be

applied to Offer Service entries that are a reaction to Find Service entries. This means

that the Subscribe Eventgroup Ack entry of a Subscribe Eventgroup entry that was

triggered by a unicast Offer Service entry is not monitored as well as upon a unicast

Offer Service entry the Stop Subscribe Eventgroup entry/Subscribe Eventgroup entry

is not sent.c(RS_SOMEIPSD_00015)

Rationale:

If a client sends a Subscribe Eventgroup entry as a reaction to a unicast offer, and a

multicast offer arrives immediately after that but before the the Subscribe Eventgroup

Ack entry could be sent by the server and received, the client shall not complain (i.e.

Stop Subscribe/Subscribe) about a not yet received acknowledgement.

Note:

This behavior exists to cope with short durations of communication loss. The receiver

of a Stop Subscribe Eventgroup and Subscribe Eventgroup combination would sent

out Initial Events to lower the effects of the loss of messages.

[PRS_SOMEIPSD_00464] dIf the initial value is of concern - i.e. for fields - the server

shall send the first notifications/events (i.e. initial events) immediately after sending the

Subscribe Eventgroup Ack.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00465] dIt is not allowed to send initial values of events upon sub-

scriptions (pure event and not field).c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00120] dThe event messages of field notifiers shall be sent on sub-

scriptions (field and not pure event).c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00121] dIf a subscription was already valid and is updated by a

Subscribe Eventgroup entry, no initial events shall be sent.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00122] dReceiving Stop Subscribe / Subscribe combinations trig-

ger initial events of field notifiers.c(RS_SOMEIPSD_00015)

79 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00123] dThe initial events shall be sent after the Subscribe Event-

group Ack.c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00466] dPublish/Subscribe States (server behavior for unicast

eventgroups) are defined as follows:

• Eventgroup_PubSub (Unicast Eventgroup)

– Service Down

– Service Up

∗ Not Subscribed

∗ Subscribed

Initial entry points of Eventgroup_PubSub (Unicast Eventgroup) are inside the

following states:

• Eventgroup_PubSub (Unicast Eventgroup)

– Service Up

Transitions inside Eventgroup_PubSub (Unicast Eventgroup) are defined as

follows:

FROM entry point Eventgroup_PubSub (Unicast Eventgroup)

TO Service Down

WITH [Service==Down]

FROM Service Down

TO Service Up

WITH ServiceUp

FROM Service Up

TO Service Down

WITH ServiceDown

FROM entry point Eventgroup_PubSub (Unicast Eventgroup)

TO Service UP

WITH [Service==Up]

FROM entry point Service Up

TO Not Subscribed

FROM Not Subscribed

TO Subscribed

80 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

WITH receive(SubscribeEventgroup) /enableEvents() send(Sub-

scribeEventgroupAck)

FROM Subscribed

TO Subscribed

WITH receive(SubscribeEventgroup) /send(SubscribeEventgroupAck)

FROM Subscribed

TO Not Subscribed

WITH receive(StopSubscribeEventgroup) /disableEvents()

FROM Subscribed

TO Not Subscribed

WITH TTL_expired [SubscriptionCounter==1] /disableEvents()

c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00016) Note: Graph-

ical information of the Publish/Subscribe States (server be-

havior for unicast eventgroups) is shown in Figure 5.24

stm Serv ice Discov ery Ev entgroup Pub/Sub (Unicast)

Ev entgroup_PubSub (Unicast Ev entgroup)

Initial

Serv ice Down

Serv ice Up

SubscribedNot Subscribed

Initial

OfferService is implicit

PublishEventgroup

AUTOSAR:

•

enableEvents = enableTxRoutingGroup

•

disableEvents = disableTxRoutingGroup

ServiceDown

ServiceUp

recei ve(SubscribeEventgroup)

/enabl eEvents()

send(SubscribeEventgroupAck)

receive(StopSubscribeEventgroup)

/disableEvents()

TTL_expired [SubscriptionCounter==1]

/disableEvents()

recei ve(SubscribeEventgroup)

/send(SubscribeEventgroupAck)

[Service==Up]

[Service==Down]

Figure 5.24: Publish/Subscribe State Diagram (server behavior for unicast eventgroups)

[PRS_SOMEIPSD_00571] dIf a client subscr ibes with different SOME/IP-SD mes-

sages to different eventgroups of the same Service Instance and all eventgroups in-

clude the same field, the Server shall send out the initial events for this field for every

subscription separately.c(RS_SOMEIPSD_00015)

81 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00572] dIf a client subscribes with one SOME/IP-SD message to

different eventgroups of the same Service Instance and all eventgroups include the

same field, the Server may choose to not send out the initial event for this field more

than once.c(RS_SOMEIPSD_00015)

Note:

This means the Server can optimize by sending the initial events only once, if supported

by its architecture.

[PRS_SOMEIPSD_00467] dPublish/Subscribe States (server behavior for multicast

eventgroups) are defined as follows:

• Eventgroup_PubSub (Multicast Eventgroup)

– Service Down

– Service Up

∗ Not Subscribed

∗ Subscribed

Initial entry points of Eventgroup_PubSub (Multicast Eventgroup) are inside

the following states:

• Eventgroup_PubSub (Multicast Eventgroup)

– Service Up

Transitions inside Eventgroup_PubSub (Multicast Eventgroup) are defined

as follows:

FROM entry point Eventgroup_PubSub (Multicast Eventgroup)

TO Service Down

WITH [Service==Down]

FROM Service Down

TO Service Up

WITH ServiceUp

FROM Service Up

TO Service Down

WITH ServiceDown

FROM entry point Eventgroup_PubSub (Multicast Eventgroup)

TO Service UP

WITH [Service==Up]

82 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

FROM entry point Service Up

TO Not Subscribed

FROM Not Subscribed

TO Subscribed

WITH receive(SubscribeEventgroup) /enableEvents() Subscription-

Counter++ send(SubscribeEventgroupAck)

FROM Subscribed

TO Subscribed

WITH receive(SubscribeEventgroup) /SubscriptionCounter++ /send

(SubscribeEventgroupAck)

FROM Subscribed

TO Not Subscribed

WITH receive(StopSubscribeEventgroup) [SubscriptionCounter==1]

/SubscriptionCounter- /disableEvents()

FROM Subscribed

TO Subscribed

WITH receive(StopSubscribeEventgroup) [SubscriptionCounter>1]

/SubscriptionCounter-

FROM Subscribed

TO Not Subscribed

WITH TTL_expired [SubscriptionCounter==1] /SubscriptionCounter-

disableEvents()

FROM Subscribed

TO Subscribed

83 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

WITH TTL_expired [SubscriptionCounter>1] /SubscriptionCounter-

c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00016) Note: Graph-

ical information of the Publish/Subscribe States (server be-

havior for multicast eventgroups) is shown in Figure 5.25

stm Serv ice Discov ery Ev entgroup Pub/Sub (Multicast)

Ev entgroup_PubSub (Multicast Ev entgroup)

Initial

Serv ice Down

Serv ice Up

SubscribedNot Subscribed

Initial

OfferService is implicit

PublishEventgroup

AUTOSAR:

•

enableEvents = enableTxRoutingGroup

•

disableEvents = disableTxRoutingGroup

ServiceDown

[Service==Up]

ServiceUp

receive(StopSubscribeEventgroup) [SubscriptionCounter>1]

/SubscriptionCounter--

TT L_expired [SubscriptionCounter>1]

/SubscriptionCounter--

recei ve(SubscribeEventgroup)

/SubscriptionCounter++

send(SubscribeEventgroupAck)

recei ve(StopSubscribeEventgroup) [SubscriptionCounter==1]

/SubscriptionCounter--

disableEvents()

TT L_expired [SubscriptionCounter==1]

/SubscriptionCounter--

disableEvents()

recei ve(SubscribeEventgroup)

/enabl eEvents()

SubscriptionCounter++

send(SubscribeEventgroupAck)

[Service==Down]

Figure 5.25: Publish/Subscribe State Diagram (server behavior for multicast event-

groups)

[PRS_SOMEIPSD_00468] dPublish/Subscribe States (server behavior for adaptive

unicast/multicast eventgroups) are defined as follows:

• Eventgroup_PubSub (Unicast-to-Multicast Eventgroup)

– Service Down

– Service Up

∗ Not Subscribed

84 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

当所有的client都stop

后，才会disable

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

∗ Subscribed (Unicast)

∗ Subscribed (Multicast)

Initial entry points of Eventgroup_PubSub (Unicast-to-Multicast Event-

group) are inside the following states:

• Eventgroup_PubSub (Unicast-to-Multicast Eventgroup)

– Service Up

Transitions inside Eventgroup_PubSub (Unicast-to-Multicast Event-

group) are defined as follows:

FROM entry point Eventgroup_PubSub (Unicast-to-Multicast Event-

group)

TO Service Down

WITH [Service==Down]

FROM Service Down

TO Service Up

WITH ServiceUp

FROM Service Up

TO Service Down

WITH ServiceDown

FROM entry point Eventgroup_PubSub (Unicast-to-Multicast Event-

group)

TO Service UP

WITH [Service==Up]

FROM entry point Service Up

TO Not Subscribed

FROM Not Subscribed

TO Subscribed (Unicast)

WITH receive(SubscribeEventgroup) [UnicastLimit>0] /en-

ableEvents() SubscriptionCounter++ send(SubscrieEventgroupAck)

FROM Subscribed (Unicast)

TO Subscribed (Unicast)

WITH receive(SubscribeEventgroup) [UnicastLimit>Subscription-

Counter] /SubscriptionCounter++ send(SubscribeEventgroupAck)

FROM Subscribed (Unicast)

TO Not Subscribed

WITH receive(StopSubscribeEventgroup) [SubscriptionCounter==1]

85 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

/SubscriptionCounter- disableEvents()

FROM Subscribed (Unicast)

TO Not Subscribed

WITH TTL_expired [SubscriptionCounter==1] /SubscriptionCounter-

disableEvents()

FROM Not Subscribed

TO Subscribed (Multicast)

WITH receive(SubscribeEventgroup) [UnicasLimit==0] /enable-

MulticastEvents() SubscriptionCounter++ send(SubscribeEvent-

groupAck)

FROM Subscribed (Multicast)

TO Not Subscribed

WITH receive(StopSubscribeEventgroup) [SubscriptionCounter==1

&& UnicasLimit==0] /SubscriptionCounter- disableMulticastEvents

()

FROM Subscribed (Multicast)

TO Not Subscribed

WITH TTL_expired [SubscriptionCounter==1 && UnicasLimit==0] /-

SubscriptionCounter- disableMulticastEvents()

FROM Subscribed (Multicast)

TO Subscribed (Multicast)

WITH receive(SubscribeEventgroup) /SubscriptionCounter++

FROM Subscribed (Multicast)

TO Subscribed (Multicast)

WITH receive(StopSubscribeEventgroup) [SubscriptionCounter>Uni-

castLimit+1] /SubscriptionCounter-

FROM Subscribed (Multicast)

TO Subscribed (Multicast)

WITH TTL_expired [SubscriptionCounter>UnicastLimit+1] /-

SubscriptionCounter-

FROM Subscribed (Unicast)

TO Subscribed (Unicast)

WITH receive(StopSubscribeEventgroup) [SubscriptionCounter>1]

86 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

/SubscriptionCounter-

FROM Subscribed (Unicast)

TO Subscribed (Unicast)

WITH TTL_expired [SubscriptionCounter>1] /SubscriptionCounter-

FROM Subscribed (Unicast)

TO Subscribed (Multicast)

WITH receive(SubscribeEventgroup) [SubscriptionCounter>=Uni-

castLimit] /SubscriptionCounter++ send(SubscribeEventgroupAck)

switchToMulticastEvents()

FROM Subscribed (Multicast)

TO Subscribed (Unicast)

WITH receive(StopSubscribeEventgroup) [Subscrip-

tionCounter==UnicasLimit+1] /switchToUnicastEvents()

SubscriptionCounter-

FROM Subscribed (Multicast)

TO Subscribed (Unicast)

WITH TTL_expired [SubscriptionCounter==UnicasLimit+1] /switch-

ToUnicastEvents() SubscriptionCounter-

c(RS_SOMEIPSD_00015, RS_SOMEIPSD_00016) Note: Graphi-

cal information of the Publish/Subscribe States (server behavior

87 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

for adaptive unicast/multicast eventgroups) is shown in Figure 5.26

stm Serv ice Discov ery Ev entgroup Pub/Sub (Unicast to Multicast)

Ev entgroup_PubSub (Unicast-to-Multicast Ev entgroup)

Initial

Serv ice Down

Subscribed

(Unicast)

Not Subscribed

Initial

AUTOSAR:

•

enableEvents = enableTxRouti ngGroup

•

disableEvents = disableT xRoutingGroup

Subscribed (Multicast)

Recei ving SubscribeEventgroup triggers sendInitialEvents

[Service==Up]

receive(SubscribeEventgroup)

[UnicastLimi t>Subscripti onCounter]

/SubscriptionCounter++

send(SubscribeEventgroupAck)

TT L_expired

[SubscriptionCounter>1]

/SubscriptionCounter--

receive(StopSubscribeEventgroup)

[SubscriptionCounter>1]

/SubscriptionCounter--

TTL_expired

[Subscri ptionCounter==1]

/Subscri ptionCounter--

disableEvents()

receive(StopSubscribeEventgroup)

[SubscriptionCounter==1]

/SubscriptionCounter--

di sableEvents()

receive(SubscribeEventgroup)

[UnicastLimi t>0]

/enableEvents()

Subscri pti onCounter++

send(SubscribeEventgroupAck)

[Service==Down]

ServiceDown

TT L_expired

[SubscriptionCounter>UnicastLimit+1]

/SubscriptionCounter--

receive(Subscri beEventgroup)

[Uni castLimit==0]

/enableMul ticastEvents()

SubscriptionCounter++

send(SubscribeEventgroupAck)

TTL_expired

[Subscri ptionCounter==UnicastLimit+1]

/switchToUnicastEvents()

SubscriptionCounter--

receive(SubscribeEventgroup)

[SubscriptionCounter>=UnicastLimit]

/SubscriptionCounter++

send(SubscribeEventgroupAck)

switchToMulticastEvents()

TTL_expired

[Subscri ptionCounter==1 &&

UnicastLimit==0]

/Subscri ptionCounter--

disableM ulticastEvents()

receive(SubscribeEventgroup)

/SubscriptionCounter++

receive(StopSubscribeEventgroup)

[SubscriptionCounter>UnicastLimit+1]

/SubscriptionCounter--

ServiceUp

receive(StopSubscribeEventgroup)

[SubscriptionCounter==1 &&

UnicastLimit==0]

/SubscriptionCounter--

di sableMul ticastEvents()

receive(StopSubscribeEventgroup)

[SubscriptionCounter==UnicastLimit+1]

/switchToUnicastEvents()

Subscri pti onCounter--

Figure 5.26: Publish/Subscribe State Diagram (server behavior for adaptive unicast/mul-

ticast eventgroups)

[PRS_SOMEIPSD_00134] Unicast/Multicast switching for event and notification

event transmission via UDP dFor events and notification events which are config-

ured to be transmitted via UDP (see [PRS_SOMEIPSD_00802]) SOME/IP-SD shall

support automated switching from unicast to multicast communication if a configured

threshold of the numbers of subscribers was reached.c(RS_SOMEIPSD_00025, RS_-

SOMEIPSD_00016)

88 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Note:

Limiting the switching between unicast and multicast to UDP is motivated by the follow-

ing rationale:

• the use of TCP is limited to unicast communication

• dynamically switching between TCP and UDP does not make sense from a se-

mantic perspective since the choice for either TCP or UDP is motivated by re-

quirements for

– reliability (no message loss, no out-of-order deliver y)

– transmission of data which is larger than the MTU (when neither SOME/IP-

TP or IP fragmentation is used)

[PRS_SOMEIPSD_00470] dSOME/IP SD Protocol shall support implicit configura-

tion of communication endpoints and registrations of subscribers. These shall be

based on static configurations and not use any SD messages on the network.c(RS_-

SOMEIPSD_00025, RS_SOMEIPSD_00015)

Note:

Depending on the project the use case can exist to use services based on a static

configuration where no Service Discovery takes place on the network at all. In such

cases of implicit registrations, there are no find or subscribe messages exchanged

but the services can be used out of the box. Such preconfigurations are not part of

SOME/IP or SOME/IP SD. Hence, their configuration and implementation is project

specific.

[PRS_SOMEIPSD_00472] dThe following entries shall be transported by unicast only:

• Subscribe Eventgroup

• Stop Subscribe Eventgroup

• Subscribe Eventgroup Ack

• Subscribe Eventgroup Nack

c(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00808] dThe client shall retry to subscribe to a Eventgroup of a

ServerService, if the SUBSCRIBE_RETRY_MAX is configured greater than 0. The sub-

scription to the Eventgroup shall be send, if a SubscribeEventgroupAck/NAck

entry of the requested Eventgroup was not received within a configurable timeout

(SUBSCRIBE_RETRY_DELAY). The retry shall be done as long as the Eventgroup is re-

quested and the configured retry count (SUBSCRIBE_RETRY_MAX) was not exceeded.c

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00809] dServerService where the TTL of the received OfferSer-

vice is set to 0xFFFFFF, could set SUBSCRIBE_RETRY_MAX to INF. In this case,

89 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

the retry shall be done as long as the Eventgroup is requested and no Sub-

scribeEventgroupAck/NAck entry of the requested Eventgroup was received.c

(RS_SOMEIPSD_00015)

[PRS_SOMEIPSD_00851] dThe automated switching from client service unicast/mul-

ticast endpoint to server service multicast endpoint has to consider configuration of

MULTICAST_THRESHOLD:

• if MULTICAST_THRESHOLD is configured to a value n with n=0, then automated

switching between client service unicast/multicast endpoints and the server ser-

vice multicast endpoint is disabled. Only unicast/multicast communication to

client service unicast/multicast endpoints is supported.

• if MULTICAST_THRESHOLD is configured to a value n with n=1, then automated

switching between client service unicast/multicast endpoints and the server ser-

vice multicast endpoint is disabled. Only multicast communication to the server

service multicast endpoint is supported.

• if MULTICAST_THRESHOLD is configured to a value n with n > 1 and the number

of subscribed clients with different endpoint information is larger than the thresh-

old or equal to the threshold, then server service shall use the server service

multicast endpoint to transmit the events.

• if MULTICAST_THRESHOLD is configured to a value n with n > 1 and the num-

ber of subscribed clients with different endpoint information is smaller than the

threshold, then the server service shall transmit the events to the endpoints which

were provided by the client services either as client service unicast endpoint or

as client service multicast endpoint.

c(RS_SOMEIPSD_00015)

5.1.7 Reserved and special identifiers for SOME/IP and SOME/IP-SD.

In this chapter an overview of reserved and special identifiers are shown.

[PRS_SOMEIPSD_00515] dReserved and special Service-IDs: Table 5.3c(RS_-

SOMEIPSD_00025)

Service-ID Description

0x0000 Reserved

0xFF00 - 0xFF1F Reserved for Testing at OEM

0xFF20 - 0xFF3F Reserved for Testing at Tier-1

0xFF40 - 0xFF5F Reserved for ECU Internal Communication (Tier-1 proprietary)

0xFFFE Reserved for non-SOME/IP service instances.

0xFFFF SOME/IP and SOME/IP-SD special service (Magic Cookie, SOME/IP-

SD, ...).

Table 5.3: Reserved and Special Service-IDs

90 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

[PRS_SOMEIPSD_00516] dReserved and special Instance-IDs: Table 5.4c(RS_-

SOMEIPSD_00025)

Instance-ID Description

0x0000 Reserved

0xFFFF All Instances

Table 5.4: Reserved and Special Instance-IDs

[PRS_SOMEIPSD_00517] dReserved and special Method-IDs: Table 5.5c(RS_-

SOMEIPSD_00025)

Method-ID Description

0x0000 Reserved

0x7FFF Reserved

0x8000 Reserved

0xFFFF Reserved

Table 5.5: Reserved and Special Method-IDs

[PRS_SOMEIPSD_00531] dReserved eventgroup-IDs: Table 5.6c(RS_SOMEIPSD_-

00025)

Eventgroup-ID Description

0x0000 Reserved

0xFFFF All Eventgroups

Table 5.6: Reserved Eventgroup-IDs

[PRS_SOMEIPSD_00519] dMethod-IDs of Service 0xFFFF: Table 5.7c(RS_-

SOMEIPSD_00025)

Method-ID/Event-

Description

0x0000 SOME/IP Magic Cookie Messages

0x8000 SOME/IP Magic Cookie Messages

0x8100 SOME/IP-SD messages (events)

Table 5.7: Method-IDs of Service 0xFFFF

[PRS_SOMEIPSD_00520] dBesides "otherserv" other names are supported by the

configuration option. The following list gives an overview of the reserved names: Table

5.8c(RS_SOMEIPSD_00025)

Name Description

hostname Used to name a host or ECU.

instancename Used to name an instance of a service.

servicename Used to name a service.

otherserv Used for non-SOME/IP Services.

Table 5.8: Reserved Names

91 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

6 Configuration Parameters

The Following chapter summarizes all the configuration parameters that are used.

Name Description

INITIAL_DELAY_MIN Minimum duration to delay randomly the transmission of

a message.

INITIAL_DELAY_MAX Maximum duration to delay randomly the transmission of

a message.

REPETITIONS_BASE_DELAY Duration of delay for repetitions.

REPETITIONS_MAX Configuration for the maximum number of repetitions.

REQUEST_RESPONSE_DELAY The Service Discovery shall delay answers using this

configuration item.

CYCLIC_OFFER_DELAY Interval between cyclic offers in the main phase.

SD_PORT is a UDP Port for SD Messages (30490 as default).

SD_MULTICAST_IP address which shall be used by the SD multicast mes-

sages.

SUBSCRIBE_RETRY_MAX Max count of retries for subscribe, as long as the Event-

group is requested (0=no retry, INF= retry forever (as

long as the Eventgroup is requested and no no Sub-

scribeEventgroupAck/Nack entry was received)).

SUBSCRIBE_RETRY_DELAY Duration of delay to send a consecutive subscribe

entries, if a Eventgroup is requested and no Sub-

scribeEventgroupAck/Nack entry was received.

MULTICAST_THRESHOLD Specifies the number of subscribed clients with differ-

ent endpoint information per Eventgroup that triggers the

server to change the transmission of events to the server

service multicast endpoint. This multicast endpoint is

configured by the server service and provided with the

SubscribeEventgroupAck:

• If configured to 0 only the client service unicast/-

multicast endpoint will be used.

• If configured to 1 the first client and all further sub-

scribed clients will be served via the server service

multicast endpoint.

• If configured to n up to n-1 clients with different

endpoint information will be served via a client

service unicast/multicast endpoint provided by the

client within the SubscribeEventgroup. As soon

as the number of subscribed clients with differ-

ent endpoint information reaches n, then all sub-

scribed clients are served via the server service

multicast endpoint.

Table 6.1: Configuration Parameters

92 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

7 Protocol Usage

7.1 Mandatory Feature Set and Basic Behavior

In this section the mandatory feature set of the Service Discovery and the relevant

configuration constraints are discussed. This allow for bare minimum implementations

without optional or informational features that might not be required for current use

cases.

The following information is defined as compliance check list(s). If a feature is not

implemented, the implementation is considered not to comply to SOME/IP-SDs basic

feature set.

[PRS_SOMEIPSD_00496] dThe following entry types shall be implemented:

• Find Service

• Offer Service

• Stop Offer Service

• Subscribe Eventgroup

• Stop Subscribe Eventgroup

• Subscribe Eventgroup Ack

• Subscribe Eventgroup Nack

c(RS_SOMEIPSD_00008, RS_SOMEIPSD_00013, RS_SOMEIPSD_00014, RS_-

SOMEIPSD_00015, RS_SOMEIPSD_00017, RS_SOMEIPSD_00007)

[PRS_SOMEIPSD_00497] dThe following option types shall be implemented, when

IPv4 is required:

• IPv4 Endpoint Option

• IPv4 Multicast Option

• Configuration Option

• IPv4 SD Endpoint Option (receiving at least)

c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00007)

[PRS_SOMEIPSD_00498] dThe following option types shall be implemented, if IPv6 is

required:

• IPv6 Endpoint Option

• IPv6 Multicast Option

• Configuration Option

• IPv6 SD Endpoint Option (receiving at least)

93 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00007)

[PRS_SOMEIPSD_00500] dThe following behaviors/reactions shall be implemented

on the Server side:

• The Server shall offer services including the Initial Wait Phase, the Repetition

Phase, and the Main Phase depending on the configuration.

• The Server shall offer services using Multicast (Repetition Phase and Main

Phase) on the multicast address defined by SD_MULTICAST_IP.

• The Server does not need to answer a Find Service in the Repetition Phase.

• The Server shall answer a Find Service in the Main Phase with an Offer Service

using Unicast (no optimization based on unicast flag).

• The Server shall send a Stop Offer Service when shutting down.

• The Server shall receive a Subscribe Eventgroup as well as a Stop Subscribe

Eventgroup and react according to this specification.

• The Server shall send a Subscribe Eventgroup Ack and Subscribe Eventgroup

Nack using unicast.

• The Server shall support controlling the sending (i.e. fan out) of SOME/IP event

messages based on the subscriptions of SOME/IP-SD. This might include send-

ing events based on Multicast.

• The Server shall support the triggering of initial SOME/IP event messages.

c(RS_SOMEIPSD_00013, RS_SOMEIPSD_00008, RS_SOMEIPSD_00014,

RS_SOMEIPSD_00015, RS_SOMEIPSD_00017, RS_SOMEIPSD_00025, RS_-

SOMEIPSD_00007)

[PRS_SOMEIPSD_00501] dThe following behaviors/reactions shall be implemented

on the Client side:

• The Client shall find services using a Find Service entry and Multicast (on the

multicast address defined by SD_MULTICAST_IP) only in the repetition phase.

• The Client shall stop finding a service if the regular Offer Service arrives.

• The Client shall react to the Servers Offer Service with a unicast SD message

that includes all Subscribe Eventgroups of the services offered in the message of

the Server that the client currently wants to subscribe to.

• The Client shall interpret and react to the Subscr ibe Eventgroup Ack and Sub-

scribe Eventgroup Nack as specified in this document.

c(RS_SOMEIPSD_00008, RS_SOMEIPSD_00015, RS_SOMEIPSD_00025, RS_-

SOMEIPSD_00007)

[PRS_SOMEIPSD_00502] dThe following behavior and configuration constraints shall

be supported by the Client:

94 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• The Client shall be able handle Eventgroups if only the TTL of the SD Timings

is specified. This means that of all the timings for the Initial Wait Phase, the

Repetition Phase, and the Main Phase only TTL is configured. This means the

client shall only react on the Offer Service by the Server.

• The Client shall answer to an Offer Service with a Subscribe Eventgroup even

without configuration of the Request-Response-Delay, meaning it should not wait

but answer instantaneously.

c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00020, RS_SOMEIPSD_00024, RS_-

SOMEIPSD_00007)

[PRS_SOMEIPSD_00503] dThe Client and Server shall implement the Reboot Detec-

tion as specified in this document and react accordingly. This includes but is not limited

to:

• Setting Session ID and Reboot Flag according to this specification.

• Keeping a Session ID counter only used for sending Multicast SD messages.

• Keeping Session ID counters for every Unicast relation for sending Unicast SD

messages.

• Understanding Session ID and Reboot Flag according to this specification.

• Keeping a Multicast Session ID counter per ECU that exchanges Multicast SD

messages with this ECU.

• Keeping a Unicast Session ID counter per ECU that exchanges Unicast SD mes-

sages with this ECU.

• Detecting reboot based on this specification and reaction accordingly.

• Correctly interpreting the IPv4 and IPv6 SD Endpoint Options in regard to Reboot

Detection.

c(RS_SOMEIPSD_00018, RS_SOMEIPSD_00007)

[PRS_SOMEIPSD_00504] dThe Client and Server shall implement the "Endpoint Han-

dling for Service and Events". This includes but is not limited to:

• Adding 1 Endpoint Option UDP to an Offer Service if UDP is needed.

• Adding 1 Endpoint Option TCP to an Offer Service if TCP is needed.

• Adding 1 Endpoint Option UDP to Subscribe Eventgroup if events over UDP are

required.

• Adding 1 Endpoint Option TCP to Subscribe Eventgroup if events over TCP are

required.

• Adding 1 Multicast Option UDP to Subscribe Eventgroup Ack if multicast events

are required.

95 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

• Understanding and acting according to the Endpoint and Multicast Options trans-

ported as described above.

• Overwriting preconfigured values (e.g. IP Addresses and Ports) with the informa-

tion of these Endpoint and Multicast Options.

• Interpreting incoming IPv4 and IPv6 Endpoint Options as SD endpoints instead

of the Address and Port number in the outer layers.

c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00013, RS_SOMEIPSD_00015, RS_-

SOMEIPSD_00007)

[PRS_SOMEIPSD_00821] dThe Client and Server shall implement the explicit request-

ing of Initial Events. (see PRS_SOMEIPSD_00703)c(RS_SOMEIPSD_00025, RS_-

SOMEIPSD_00013, RS_SOMEIPSD_00015, RS_SOMEIPSD_00007)

7.2 Migration and Compatibility

7.2.1 Supporting multiple versions of the same service.

In order to support migrations scenarios ECUs shall support serving as well as using

different incompatible versions of the same service.

[PRS_SOMEIPSD_00512] dIn order to support a Service with more than one version

the following is required:

• The server shall offer the service instance of this service once per major version.

• The client shall find the service instances once per supported major version or

shall use the Major Version as 0xFF (all versions).

• The client shall subscribe to events of the service version it needs.

• All SOME/IP-SD entries shall use the same Service-IDs and Instance-IDs but

different Major Versions.

• The server has to demultiplex messages based on the socket they arr ive,

Message-ID, Major Versions and relay it based on these conditions internally to

the correct receiver.

c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00008, RS_SOMEIPSD_00013, RS_-

SOMEIPSD_00015, RS_SOMEIPSD_00005)

[PRS_SOMEIPSD_00806] dIn one VLAN there shall be at most one service instance

with the same Service ID, Major Version and Instance ID. This applies to the server

and to the client Network Nodes.c(RS_SOMEIPSD_00025, RS_SOMEIPSD_00008,

RS_SOMEIPSD_00013, RS_SOMEIPSD_00015, RS_SOMEIPSD_00005)

96 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

Note: Configuring more than one service instance on one Network Node that differs

only in the Minor Version is not allowed since they can not be distinguished in Event-

group entries.

97 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol

SOME/IP Service Discovery Protocol Specification

AUTOSAR FO R22-11

8 References

References

[1] Glossary

AUTOSAR_TR_Glossary

98 of 98 Document ID 802: AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol